Echando la vista atrás, al HC yo le veo muchos más inconvenientes que ventajas. Quizás la principal ventaja que a mucha gente se le puede pasar por la cabeza es que te ahorras el dinero del hosting, y así puede ser en algunos casos, pero con varios peros.
Si de lo que estamos hablando es de alojar un blog, la realidad es que tanto WordPress.com como Blogger dan un servicio gratuito excelente. WordPress.com (que no hay que confundir con el CMS WordPress, alojado en WordPress.org) lo hace a cambio de publicidad que muestran muy poco a menudo y no permiten que nosotros pongamos nuestra propia publicidad. Blogger sí que permite incluir anuncios de AdSense. A mí personalmente me desagradan los anuncios de AdSense, pero entiendo que éste pueda ser un factor importante a la hora de alojar nuestro blog en un sitio o en otro. Si queremos tener el blog en un dominio propio, WordPress.com nos lo permite por tan sólo 10$ al año, y Blogger también lo permite gratis (por supuesto, el coste de la compra del dominio va aparte).
Para alojar páginas estáticas, Google Pages podría valernos perfectamente.
Para tener e-mail, alojar páginas estáticas o almacenar documentos con nuestro propio dominio, Google Apps nos lo pone muy fácil. Además, Google recientemente ha añadido a la lista de aplicaciones de Google Apps el Google Sites, que nos permitirá tener un Structured Wiki también en nuestro propio dominio.
Si nada de lo anterior nos satisface por completo por falta de versatilidad para lo que queremos hacer, un hosting puede ser razonablemente barato. No soy la persona más indicada para recomendar uno, pero por ejemplo, SigT, un blog cuyo criterio se puede tener muy en cuenta, está en Dreamhost, y no parece que estén descontentos, aunque pueden contarnos algunas batallitas. Iñaki Silanes también se pasó hace poco a Dreamhost. El plan estándar de Dreamhost, que incluye SSH y 5TB de transferencia mensual, sale por 10.95$/mes si contratamos un mes, 9.95$/mes si contratamos un año, 7.95$/mes si contratamos 3 años y 5.95$/mes si contratamos 10 años. Yo llevo poco tiempo en 1and1.es y no tengo ninguna queja sobre ellos, pero en precio y características, definitivamente no son competitivos comparando con Dreamhost.
Además, tener un ordenador siempre encendido en casa no es exactamente gratis: además de la electricidad que gasta, sus componentes se van desgastando, sobre todo el disco duro, y si tenemos que reemplazar un disco duro, por menos de unos 60€ seguramente no lo podamos hacer.
El HC tiene muchas otras desventajas, entre las que podemos citar:
Intervalos sin servicio.
Poco ancho de banda de subida.
Según el servidor usado, es posible que tengamos poca velocidad de respuesta y las páginas dinámicas no se generen rápidamente.
Poca capacidad de respuesta ante picos inesperados de tráfico.
Disponibilidad reducida del ordenador que usemos como servidor para otras tareas.
Disponibilidad reducida del ancho de banda del que dispongamos para otras tareas (p.e. P2P).
No es lo más recomendable tener un dispositivo eléctrico 24×7 encendido: Aunque no es lo más probable, el cable se podría calentar, derretir, generar un cortocircuito y causar un incendio.
Preocupación por si el servicio se está dando correctamente.
¿Qué haces con el servidor cuando te vas a ausentar de casa por un espacio prolongado de tiempo?
¿Cómo reaccionar rápidamente ante una avería hardware?
¿Qué haces si se va la luz?
Es necesario invertir tiempo en la administración del servidor.
¡Uy! ¡Que mal lo hemos pintado! ¿Y no tiene ninguna ventaja el HC? Pues sí, hay una y muy grande, que puede compensar con creces todos los inconvenientes anteriores:
–== APRENDER ==–
¡Y así es! Porque del HC, lo más provechoso es lo que se aprende de las tecnologías web. Con él podremos ver cómo configurar Apache, cómo reparar nuestras bases de datos MySQL, cómo mantener nuestro sistema estable para tener que hacer el mínimo número de paradas posible, cómo crearnos scripts para tener todos los aspectos de nuestro servidor monitorizados y controlados, cómo estudiar los logs, cómo… ¡administrar un servidor web de verdad que sirve páginas de verdad!
En mi caso, además, que uso WordPress, el hosting casero me ha permitido hacer lo que he querido con él. He modificado el código como me ha parecido y he instalado los plugins que me han parecido útiles sin las restricciones de WordPress.com. Gracias a eso, también he aprendido un poco de PHP.
Bueno, ¿qué has pensado? ¿Sigues queriendo montar tu propio HC? ¡Pues sigue leyendo!
El servidor
¡No, no, no! No puedes usar tu nuevo y flamante Quad-Core con 8GB de RAM, una NVidia 8800GTX, 4 discos en RAID y fuente de 1000W como servidor de HC. Estoy de acuerdo que ninguno mejor que ese generará las páginas dinámicas y hará volar al Apache pero: ¿No es ese el ordenador que vas a usar para todo lo demás? ¿Con ese pedazo de tarjeta de vídeo no vas a usarlo para algún juego 3D? ¿Seguro que lo reiniciarás lo justo? ¿Tú te has dado cuenta del ruido que hacen sus ventiladores? Además, el precio del kWh es de unos 0.09 ceńtimos de €, así que a poco que consuma 300W, estamos hablando de 300x24x365x0.09/1000=236€ al año (o 19€ al mes).
Sí, ese Pentium III/4/AMD K7 que tienes ahí parado desde hace meses y que no sabes bien qué hacer con él te podría servir, pero apostaría sin dudarlo mucho a que también consume lo suyo y a que hace incluso más ruido que el nuevo. Es una buena opción, y si no te importa mucho el consumo eléctrico, definitivamente podría ser lo que necesitamos. Sin embargo, recordemos que tu casa es ese sitio al que vas después de un duro día y donde esperas encontrar paz, tranquilidad y el descanso del guerrero. Llegar y encontrarte ese odioso ordenador haciendo ruido un día y otro, y otro también y sin que te puedas permitir apagarlo, quizás no es lo que más te apetezca. Sí, ya sé que tú tal vez ya tienes ese mismo ordenador muchos días encendido bajando cosas con aMule y con Bittorrent, pero de vez en cuando lo apagas, ¿no? ¡Ah! ¿Cómo? ¿Que noooooo?
Bueno, a lo que quería llegar, es que a menos que tengáis una casa de 200m2 con una habitación por ahí perdida donde encerrar el ordenador bajo llave para no oírlo, seguramente necesitéis otra cosa. Si lo que queremos es el servidor perfecto para un HC profesional, válgame la contradicción, lo que nos hace falta es un ordenador de bajo consumo y sin ventiladores.
Hasta hace poco, los procesadores líderes indiscutibles en esta categoría eran los VIA C3 y C7, de los que he hablado extensamente en este blog. Las placas VIA EPIA de formato Mini-ITX han sido durante mucho tiempo elecciones excelentes para este propósito; los drivers para el procesador gráfico no son lo mejor del mundo, pero no es algo realmente importante si sólo la vamos a usar como servidor. Hay otros fabricantes que tienen placas con procesador integrado y chipset de VIA, como las Jetway, las eBox (distribuidas en España por EPATec) o la Elite C7VCM (con fuente de alimentación DC-DC integrada), todas ellas más baratas que las VIA EPIA, pero no creo que me equivoque mucho si digo que probablemente hay muchísima más documentación y experiencia sobre las VIA EPIA que sobre otros modelos (sin entrar en la teórica superior calidad de unas sobre otras).
Pero decía “hasta hace poco” porque Intel y AMD no están indiferentes ante este trozo de mercado de procesadores/placas sin ventilador y de bajo consumo. AMD hace tiempo que tiene los procesadores AMD Geode, aunque la verdad es que no han sido muy populares en el segmento de mercado de los procesadores VIA, tal vez porque hasta la salida del Geode NX, el rendimiento de sus predecesores era muy pobre (ejemplos de placas con AMD Geode: ALIX2C2, Albatron KI741CX).
Nota: Gracias a Tostadilla por varios de los enlaces.
Intel, por su parte, está a punto de descabalgar a sus competidores también en este segmento de mercado igual que ha hecho con AMD en los segmentos de procesadores para ordenadores de sobremesa y en procesadores para portátiles. Su nueva placa base D210GLY, con procesador de refrigeración pasiva Intel Celeron 215 (con arquitectura Core) a 1.2GHz, con un consumo equiparable a las VIA EPIA, y con un precio de 69.50$, es un misil directo a la línea de flotación de las VIA EPIA. Yo no he probado una de estas placas, pero dado el historial de productos de calidad de Intel y su compromiso con la creación de drivers de código abierto, no dudaría ni un momento en recomendar una de estas placas por delante de las de VIA. Por no decir que seguro que a igualdad de frecuencia de reloj, uno de estos Celeron tiene mucho más rendimiento que uno de VIA. Josemanu de La Factoría Secreta acaba de cambiar su VIA EPIA por una de estas placas… ¡a ver qué nos va contando sobre ella!
Respecto a otros aspectos del servidor, sólo cabría mencionar la memoria RAM y tal vez el disco duro, pero como cualquier tamaño de disco duro superior a los 10GB será más que suficiente para casi cualquier propósito, quizás lo más determinante pueda ser la RAM. En mi opinión, una cantidad razonable de RAM para manejar con soltura varias peticiones de Apache y el MySQL son 512MB, pero 256MB podrían ser suficientes.
Para finalizar la sección, comentar que un portátil definitivamente no es una opción como servidor. Pero ni como servidor de HC ni para tenerlo siempre encendido con programas P2P. Un portátil es un portátil. No están preparados en absoluto para un estado de sobrecalentamiento permanente y a sus pequeños discos duros de 2.5″ no les gusta que les tengan permanentemente dando vueltas y estarán condenados con mucha probabilidad a una muerte prematura si les obligas a ello.
Y no se me olvidan los dispositivos de ultra-bajo-consumo que aceptan Linux, como el NSLU2, el LinkStation, la KuroBox o la EFIKA. Aunque se les pueda instalar Linux, en mi opinión no dan la talla para un servidor web completo como el que nos ocupa.
Por cierto, Intel está a punto de revolucionar aún más el panorama de los procesadores de bajo consumo con la llegada de los Ultra-Mobile PC (UMPC) y sus procesadores: A100/A110 y su reciente Atom (via Blog Staredsi).
El proveedor de Internet
Evidentemente, necesitaremos un acceso de banda ancha a Internet, y con este acceso llegará nuestra mayor limitación: el ancho de banda de subida. El acceso de banda ancha más común actualmente en España es el ADSL de 3Mbps de bajada y de 320kbps de subida. La bajada nos importa bien poco, pero la subida es lo que definitivamente determinará el máximo número de usuarios que podremos atender simultáneamente con una cierta fluidez.
Esos 40KB/s teóricos de subida pueden parecer poco, pero no son desdeñables, ya que pueden suponer una transferencia máxima mensual teórica de más de 100GB, bastante superior a lo que ofrecen muchos hostings:
320x3600x24x31/8/106=107GB
1KB=103Bytes, 1GB=106Bytes
Sin embargo, evidentemente, esta no es una comparación del todo justa, ya que no podemos esperar que el flujo de visitas sea regular, sino que la naturaleza de la web nos trae precisamente lo contrario; exceptuando el tráfico procedente de los buscadores que tal vez sí sea razonablemente uniforme, las visitas normalmente las tendremos a rachas: a ciertas horas del día, cuando se nos cita y enlaza desde otras páginas o cuando publicamos algo nuevo. Si se nos amontonan las visitas, las páginas tardarán considerablemente más en ser descargadas y la experiencia del usuario en nuestra página podría llegar a ser muy pobre, …y eso si no se cansa de esperar y definitivamente la cierra sin que acabe de cargarse.
Por tanto, ¿son suficientes esos 40KB/s para dar un servicio razonable? En mi experiencia, en principio, sí, pero vamos a tener que ser cuidadosos con el material que servimos y tenemos que tener bien claro que ante un pico brutal de visitas, vamos a fracasar sin remedio.
Por supuesto, no sólo existe la oferta de los 320kbps de subida. Ahora mismo también hay otras compañías de ADSL que ofrecen hasta 1Mbps de subida (con sus “hasta” 20Mbps de bajada). Sin embargo, cuando en algún momento me he planteado contratar alguna de esas alternativas, siempre me he encontrado docenas de mensajes en los foros de personas quejándose de cortes y microcortes frecuentes y reiterados que me han desanimado. Al final, la calidad de una de estas líneas con ADSL 2+ dependerá del ruido de la línea y de la distancia del par de cobre hasta la central telefónica, pero en el mejor de los casos, su calidad parece claramente insuficiente si queremos dar un servicio de la forma más estable posible.
Por otra parte, el panorama parece que va a mejorar mucho y muy pronto. ONO ya ofrece 1Mbps de subida, que tal vez sean más estables que los del ADSL 2+ y la aparición del VDSL2 de la mano de Telefónica es inminente, al mismo tiempo que se acerca el FTTH.
Otro aspecto que podemos plantarnos es la conveniencia de la IP fija. En Telefónica sale por 12€ al mes, y nos podría facilitar enormemente muchos aspectos del HC. Sin embargo, sólo por lo que cuesta, podríamos contratar un hosting profesional, de modo que es una opción que la mayoría descartaríamos.
El dominio
Por supuesto, vamos a necesitar uno o más dominios para hacer realidad nuestro proyecto. Si tuviéramos una IP fija, podríamos comprar un dominio a cualquier registrador y hacer que el DNS apuntara a nuestra IP fija. En nuestro servidor tendríamos que configurar un servidor de DNS además de todos los otros servicios que quisiéramos proporcionar.
Sin embargo, con una IP dinámica también podremos montar nuestro HC sin problemas gracias a empresas como DynDNS o no-ip.com. En ¿Piensas en si un día te roban el portátil? ya vimos una introducción a cómo funcionan estos servicios y una guía de configuración del ddclient en Debian para que actualice la IP tan pronto como ésta cambie. Suponiendo dicha teoría sabida, vamos a ver cómo ajustar la configuración de DynDNS al entorno de un HC como el que estamos montando.
DynDNS pone a nuestra disposición un gran número de dominios base sobre el que crear hostnames (hasta 5 por cuenta) como por ejemplo:
barriosesamo.homelinux.org
gustavo.blogsite.org
supercoco.is-a-geek.org
Los dominios disponibles tienen nombres bastante útiles y llamativos, de forma que resulta bastante fácil encontrar una combinación que sea de nuestro agrado. La mía, como los más viejos del lugar saben, fue y es valencia.homelinux.org. Si queremos asociar una IP dinámica a un dominio propio, podemos considerar la opción de comprar el servicio Custom DNS, que sale por 27.5$ al año. Si también compramos el dominio en DynDNS, por ejemplo, uno .com por 15$, al hacer la compra conjunta con el Custom DNS nos hacen un descuento de 5$. Por tanto, la broma de Custom DNS + Dominio nos saldrá por 37.5$/año. En DynDNS no podemos comprar un dominio .es, pero si lo compramos en otro sitio, podemos hacerlo funcionar con el servicio Custom DNS de DynDNS.
Yo compré el dominio vicente-navarro.com con el servicio Custom DNS y la configuración del ddclient para actualizar puntualmente ambos dominios era (/etc/ddclient.conf):
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
pid=/var/run/ddclient.pid
protocol=dyndns2
use=web, web=checkip.dyndns.org/, web-skip='IP Address'
wildcard=yes
server=members.dyndns.org
login=supercoco
password=contrasenyadesupercoco
valencia.homelinux.org
custom=yes, vicente-navarro.com
Como vemos, la única diferencia entre actualizar un hostname de los gratuitos y uno de los Custom DNS es la cadena custom=yes. www.vicente-navarro.com puede ser un CNAME a vicente-navarro.com o podría ser un hostname diferente, en cuyo caso tendríamos que añadir una línea adicional en el ddclient.conf.
La línea:
use=web, web=checkip.dyndns.org/, web-skip='IP Address'
sirve para especificarle al ddclient dónde encontrar la IP a usar para actualizar el servidor de DNS. Poniendo use=web le decimos que acceda a una web (en este caso checkip.dyndns.org) para consultarla. Si nuestro servidor tuviera directamente la IP pública de Internet en uno de sus interfaces, algo cada vez más raro hoy en día, podríamos poner algo así:
use=if, if=eth0
El ddclient es capaz de conectarse a ciertos routers de diferentes formas para obtener la dirección directamente del router. Podemos consultar todas las posibilidades en la documentación del ddclient.
Para probar el correcto funcionamiento del ddclient, es una buena idea usar la opción -v y la -force también puede ser necesaria para hacer troubleshooting ya que el cliente se niega a enviar una actualización al servidor de DNS si la IP no ha cambiado (lo sabe por la caché que mantiene en /var/cache/ddclient/ddclient.cache):
# ddclient -v -force
CONNECT: checkip.dyndns.org
CONNECTED:
SENDING: GET / HTTP/1.0
SENDING: Host: checkip.dyndns.org
SENDING: User-Agent: ddclient/3.6.7
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Content-Type: text/html
RECEIVE: Server: DynDNS-CheckIP/1.0
RECEIVE: Connection: close
RECEIVE: Cache-Control: no-cache
RECEIVE: Pragma: no-cache
RECEIVE: Content-Length: 105
RECEIVE:
RECEIVE: <html><head><title>Current IP Check</title></head><body>Current IP Address: 81.39.245.141</body></html>
INFO: forcing update of valencia.homelinux.org.
INFO: forcing update of vicente-navarro.com.
INFO: setting IP address to 81.39.245.141 for valencia.homelinux.org
UPDATE: updating valencia.homelinux.org
CONNECT: members.dyndns.org
CONNECTED:
SENDING: GET /nic/update?system=dyndns&hostname=valencia.homelinux.org&myip=81.39.245.141&wildcard=ON HTTP/1.0
SENDING: Host: members.dyndns.org
SENDING: Authorization: Basic dmluYWpvOmxhZW5jb250cmFzdGU6LSk=
SENDING: User-Agent: ddclient/3.6.7
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Date: Sat, 08 Mar 2008 10:12:15 GMT
RECEIVE: Server: Apache
RECEIVE: X-UpdateCode: n
RECEIVE: Content-Type: text/plain
RECEIVE: Connection: close
RECEIVE:
RECEIVE: good 81.39.245.141
SUCCESS: updating valencia.homelinux.org: good: IP address set to 81.39.245.141
INFO: setting IP address to 81.39.245.141 for vicente-navarro.com
UPDATE: updating vicente-navarro.com
CONNECT: members.dyndns.org
CONNECTED:
SENDING: GET /nic/update?system=custom&hostname=vicente-navarro.com&myip=81.39.245.141&wildcard=ON HTTP/1.0
SENDING: Host: members.dyndns.org
SENDING: Authorization: Basic dmluYWpvOmxhZW5jb250cmFzdGU6LSk=
SENDING: User-Agent: ddclient/3.6.7
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Date: Sat, 08 Mar 2008 10:12:15 GMT
RECEIVE: Server: Apache
RECEIVE: X-UpdateCode: n
RECEIVE: Content-Type: text/plain
RECEIVE: Connection: close
RECEIVE:
RECEIVE: good 81.39.245.141
SUCCESS: updating vicente-navarro.com: good: IP address set to 81.39.245.141
En el fichero /etc/default/ddclient podemos especificar si queremos que ddclient funcione como un demonio, que es lo recomendable (otra opción es planificar el ddclient en el cron) y cada cuánto tiempo debería de chequear si ha habido un cambio de IP (5 minutos por defecto, si lo ponemos más frecuente, es posible que nos denieguen el acceso por abuso del servicio):
# Configuration for ddclient scripts
# generated from debconf on Sat Mar 10 13:45:30 CET 2007
#
# /etc/default/ddclient
# Set to "true" if ddclient should be run every time a new ppp connection is
# established. This might be useful, if you are using dial-on-demand
run_ipup="false"
# Set to "true" if ddclient should run in daemon mode
run_daemon="true"
# Set the time interval between the updates of the dynamic DNS name in seconds.
# This option only takes effect if the ddclient runs in daemon mode.
daemon_interval="300"
Por tanto, cada vez que el ISP nos cambie la IP (algo que normalmente no ocurre en semanas) nos encontraremos con que tendremos unos pocos minutos sin servicio. Otra opción, la óptima, es que nuestro router soporte el protocolo de DynDNS y sea capaz de actualizar el servidor de DNS cada vez que detecte un cambio de IP en la interfaz de WAN. Mi Zyxel 660HW lo soporta, por lo que sí que es capaz de actualizar un hostname como valencia.homelinux.org, pero no es capaz de gestionar hostnames de dominios Custom DNS por defecto:
ynDNS mantiene una lista de dispositivos hardware con un cliente DynDNS integrado certificado. El popular Linksys WRT54G es uno de ellos y soporta Custom DNS poniendo una coletilla al nombre del dominio: example.com&system=custom. De todas formas, DynDNS prefiere los clientes software.
Para finalizar, podemos comentar la lista de servicios que ddclient soporta según su README, por si preferimos uno alternativo a DynDNS:
Dynamic DNS services currently supported include:
DynDNS.org - See http://www.dyndns.org for details on obtaining a free account.
Hammernode - See http://www.hn.org for details on obtaining a free account.
Zoneedit - See http://www.zoneedit.com for details.
EasyDNS - See http://www.easydns.com for details.
NameCheap - See http://www.namecheap.com for details
El sistema operativo
A estas alturas, nadie se puede sorprender de que yo recomiende como sistema operativo de nuestro servidor de HC la última versión estable de Debian (en estos momentos la Debian Etch 4.0) con sus correspondientes actualizaciones de seguridad. Las versiones estables de Debian tienen mucha fama por su gran estabilidad a costa de llevar versiones menos recientes pero mucho más probadas. Cuando me pasé a 1and1.es, una de las agradables sorpresas que me llevé fue ver que usaban Debian en sus servidores.
Hace unas semanas, cuando se hizo público el famoso exploit que afectaba a casi todas las versiones del kernel, el equipo de seguridad de Debian se apuntó un buen tanto al ser la primera en distribuir un parche de seguridad para el problema. Pero de todas formas, cualquier distribución de Linux bien mantenida, estable y con constantes actualizaciones de seguridad es perfectamente válida para nuestro propósito.
Y eso sin querer hacer un desprecio a las diferentes *BSD, que pueden ser una opción tanto o más buena que cualquier Linux, quizás destacando OpenBSD por su foco en la seguridad.
Y Windows… pues bueno, se podría tener un servidor de HC con Windows, pero las posibilidades de gestión y actualización remota se reducirían drásticamente. Definitivamente, no es la mejor opción.
El router
En la mayoría de los casos, nuestro servidor de HC estará detrás de un router que será el que tenga la IP pública del interfaz de WAN y que distribuirá el tráfico entre los equipos conectados a la LAN. Además, no es que sea lo más típico, es que a menos que el servidor de HC sea el único sistema que vaya a acceder a Internet en la casa, tampoco existe otra opción válida.
El router tenemos que configurarlo para que nuestro servidor de HC siempre reciba la misma dirección IP por DHCP, algo que la mayoría de routers soportan asociando una dirección MAC determinada con una misma IP. Otra opción es configurar el servidor para que use una IP fija y no la obtenga por DHCP, opción más segura que la primera, pero tendremos que usar una IP fuera del rango de direcciones DHCP que concede el router aunque dentro de la misma subred.
Además, tendremos que abrir como mínimo el puerto 80 y configurar el NAT para que las peticiones a dicho puerto vayan a la IP que hemos asignado a nuestro servidor. Otro puerto fundamental es el 22 para permitir el acceso por SSH y así poder hacer mantenimiento remoto del servidor. Opcionalmente, podemos abrir el 25 para SMTP y tal vez el 110 (POP3) y el 143 (IMAP).
Los sistemas de la LAN distintos al servidor probablemente no podrán usar el servidor de nombres de Internet para acceder a los servicios que proporciona el servidor (por ejemplo, para ver nuestra página web desde otro sistema de la red), porque el dominio resuelve a una IP que tiene el router, por lo que le estaremos mandado las peticiones al router, no al servidor de HC. Es por ello que, o montamos un pequeño DNS que dé servicio a la LAN, o introducimos en el fichero /etc/hosts de todos los sistemas (incluso en los Windows en c:windowssystem32driversetchosts) una referencia a los hostnames de todos los servicios que tengamos hospedados:
192.168.1.30 www.vicente-navarro.com vicente-navarro.com
192.168.1.30 valencia.homelinux.org
Para finalizar, una advertencia sobre el Wi-Fi y su inconveniencia para nuestro propósito. Nuestro servidor de HC debería estar conectado por cable al router. La conexión Wi-Fi, aunque nos pueda parecer que normalmente es muy estable, está sujeta a muchas interferencias sobre las que no tenemos control. Y de entre esas interferencias, yo destacaría la de los vecinos. En mi casa, por ejemplo, yo detecto multitud de señales Wi-Fi diferentes de vecinos que me provocan graves interferencias y que ni siquiera me permiten recibir la señal del router en otra habitación por muchos cambios de canal que pruebe, por lo que me tuve que cablear la casa. Otros casos pueden ser menos graves, pero en cualquier momento puedes encontrarte con que la señal del vecino causa interrupciones en la tuya. Definitivamente, no parece lo más conveniente.
El servidor web
Hablar de servidor web en un sistema UNIX es casi sinónimo de hablar de Apache. Siempre quise probar el lighttpd, pero nunca llegué a ponerme manos a la obra, así que no puedo contar de primera mano qué tal funciona en un sistema modesto como el mío, pero en general, tiene muy buena prensa, especialmente en lo que toca a consumo de memoria. En la gráfica de Febrero de Netcraft, vemos que lighttpd ya va haciéndose ver con su millón y medio de sitios que lo usan. Creo que es un candidato excelente como servidor web para nuestro HC.
Volviendo a Apache, todas las distribuciones tienen un paquete de Apache perfectamente listo para instalar y comenzar a trabajar; cada una con sus peculiaridades de configuración. Lo primero que tendremos que elegir es si queremos Apache 1.3 o Apache 2.x, un viejo debate en el que yo no me atrevo a entrar. Para el desarrollo de Apache 2.0 se reescribió la mayor parche del código y su mayor novedad fue que funcionaba con threads UNIX. Aunque su rendimiento es mejor en general, su adopción ha sido muy lenta porque muchos de los módulos existentes para Apache 1.3 no existían en Apache 2.x y porque la documentación de PHP desaconsejaba usarlo. En la actualidad, las instrucciones de instalación de PHP en entornos con Apache 2 muestran la siguiente advertencia:
Warning
We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM
En Debian tenemos paquetes para Apache 1.3 y para Apache 2.2. En el caso de Apache 2, con distintas posibilidades de MPM (Multi-Processing Module):
apache - versatile, high-performance HTTP server
apache-common - support files for all Apache webservers
apache-dbg - debug versions of the Apache webservers
apache-dev - development kit for the Apache webserver
apache-doc - documentation for the Apache webserver
apache-perl - versatile, high-performance HTTP server with Perl support
apache-ssl - versatile, high-performance HTTP server with SSL support
apache2 - Next generation, scalable, extendable web server
apache2-doc - documentation for apache2
apache2-mpm-event - Event driven model for Apache HTTPD 2.1
apache2-mpm-itk - multiuser MPM for Apache 2.2
apache2-mpm-perchild - Transitional package - please remove
apache2-mpm-prefork - Traditional model for Apache HTTPD 2.1
apache2-mpm-worker - High speed threaded model for Apache HTTPD 2.1
apache2-prefork-dev - development headers for apache2
apache2-src - Apache source code
apache2-threaded-dev - development headers for apache2
apache2-utils - utility programs for webservers
apache2.2-common - Next generation, scalable, extendable web server
El paquete apache2-mpm-prefork es el que necesitamos según la documentación de PHP (Apache MPM prefork). Si miramos su descripcción, vemos que permite usar Apache 2 de una forma similar a la que funcionaba Apache 1.3 evitando problemas con librerías que no son thread-safe a cambio de algo de rendimiento:
$ apt-cache show apache2-mpm-prefork
[...]
Description: Traditional model for Apache HTTPD 2.1
This Multi-Processing Module (MPM) implements a non-threaded,
pre-forking web server that handles requests in a manner similar to
Apache 1.3. It is appropriate for sites that need to avoid threading for
compatibility with non-thread-safe libraries. It is also the best MPM
for isolating each request, so that a problem with a single request will
not affect any other.
.
It is not as fast, but is considered to be more stable.
[...]
Y, de hecho, podemos comprobar que es un prerequisito para instalar el mod-php5:
$ apt-cache show libapache2-mod-php5
[...]
Depends: libbz2-1.0, libc6 (>= 2.3.6-6), libcomerr2 (>= 1.33-3), libdb4.4, libkrb53 (>= 1.4.2),
libpcre3 (>= 4.5), libssl0.9.8 (>= 0.9.8c-1), libxml2 (>= 2.6.27), zlib1g (>= 1:1.2.1),
mime-support (>= 2.03-1), apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-itk,
apache2.2-common, php5-common (= 5.2.0-8+etch10), libmagic1, ucf
[...]
Los diferentes paquetes apache2-mpm-* lo que hacen es instalar un binario principal de Apache diferente:
$ dpkg -L apache2-mpm-prefork | egrep 'bin|lib'
/usr/sbin
/usr/sbin/apache2
El módulo de MPM que Debian instala por defecto si hacemos un simple “apt-get install apache2” es el apache2-mpm-worker (Apache MPM worker), pero si instalamos el mod-php5, es reemplazado por el apache2-mpm-prefork.
En definitiva, para instalar con un sólo comando un sistema LAMP (Linux+Apache+MySQL+PHP) en Debian, sólo necesitaremos ejecutar el siguiente comando:
# apt-get install apache2 libapache2-mod-php5 php5-mysql mysql-server-5.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]
The following NEW packages will be installed:
apache2 apache2-mpm-prefork apache2-utils apache2.2-common libapache2-mod-php5 libdbd-mysql-perl
libdbi-perl libmysqlclient15off libnet-daemon-perl libplrpc-perl libterm-readkey-perl mysql-client-5.0
mysql-common mysql-server-5.0 php5-common php5-mysql
[...]
Las versiones de Debian Etch son razonablemente recientes: Apache 2.2, MySQL 5.0 y PHP 5. Creo que en un sistema que montamos a nuestro gusto para aprender, tampoco vale la pena irnos a las versiones más viejas. Los hostings profesionales ya son bastante rácanos en cuanto al uso de versiones modernas (¡hace poco me encontré con uno que aún usaba MySQL 3!), como para que nosotros les emulemos. Si la versión es estable para Debian, también lo es para mí.
Por tanto, una vez que tenemos el Apache 2.2 instalado, en Debian tenemos un fichero de configuración global en /etc/apache2/apache2.conf. Desde ese fichero se incluye el /etc/apache2/httpd.conf, que por defecto está vacío y preparado para que nosotros introduzcamos nuestras líneas de configuración personalizadas sin tener que alterar el principal. En el fichero ports.conf se especifica el puerto a usar, por defecto el 80. Luego tenemos los directorios de /etc/apache2/:
mods-available/
mods-enabled/
sites-available/
sites-enabled/
En el mods-available tenemos los módulos instalados en el sistema. En el sites-available tenemos todos los sitios virtuales configurados en el sistema. En los directorios mods-enabled y sites-enabled tenemos enlaces a los módulos y sitios virtuales que queremos habilitar. En las entradas de compresión y cacheo de Apache vimos cómo habilitar y configurar los módulos:
Probando el mod_deflate de Apache
Usando el mod_cache de Apache para que el mod_deflate no incremente la carga del servidor
Los enlaces los podemos crear y eliminar a mano o con las siguientes herramientas de Debian:
a2dismod a2dissite a2enmod a2ensite
Tenemos más información sobre los aspectos particulares de configuración de Apache en Debian en el fichero /usr/share/doc/apache2.2-common/README.Debian.
Configuración de los sitios virtuales
Por defecto, Debian sólo nos deja un sitio virtual configurado en /etc/apache2/sites-available/default que es el que por defecto se usa cuando se accede con un hostname que no tiene una configuración de sitio virtual específica. Tiene el directorio base de documentos en /var/www/apache2-default/ y nos permite recorrer la documentación del servidor sólo desde el navegador del propio servidor, http://localhost/doc/:
NameVirtualHost *
<VirtualHost *>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
RedirectMatch ^/$ /apache2-default/
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>
La configuración básica de sitio virtual que yo usaba (/etc/apache2/sites-available/vicente-navarro.com, con enlace en sites-enabled) era:
<VirtualHost *>
ServerName vicente-navarro.com
ServerAlias www.vicente-navarro.com
DocumentRoot /var/www/vicente-navarro.com/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/vicente-navarro.com/>
Options FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error_vn.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access_vn.log combined
ServerSignature On
</VirtualHost>
Sobre ella, podemos hacer algunos cambios:
Si queremos permitir la configuración con ficheros .htaccess, tendremos que quitar las líneas “AllowOverride None“.
Si queremos presentar un documento personalizado para errores 404, podemos incluir una línea como: “ErrorDocument 404 /404.php“.
Por otra parte, teniendo en cuenta que nuestro ancho de banda de subida es muy limitado, el hotlinking (enlace a las imágenes de nuestro sitio desde otro sitio) es especialmente dañino, por lo que deberíamos de prevenir hasta donde sea posible el “robo de imágenes”. Una buena forma de hacerlo es rechazando las peticiones cuyo referer no sea nuestra propia página o ninguno (hay firewalls que los eliminan, la extensión No-Referer de Firefox también los elimina, e incluso podemos controlarlo en Firefox con el parámetro Network.http.sendRefererHeader). How can I prevent people from “stealing” the images from my web site?:
SetEnvIf REFERER "vicente-navarro.com" linked_from_here
SetEnvIf REFERER "^$" linked_from_here
<FilesMatch ".(gif|jpg|png)">
Order deny,allow
Deny from all
Allow from env=linked_from_here
</FilesMatch>
Además, en mi caso, cuando cambié el dominio principal de valencia.homelinux.org a www.vicente-navarro.com, tuve que implementar una redirección 301, para lo que creé un sitio virtual en /etc/apache2/sites-available/valencia.homelinux.org:
<VirtualHost *>
ServerName valencia.homelinux.org
Redirect permanent / http://www.vicente-navarro.com/blog/
ErrorLog /var/log/apache2/error_vho.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access_vho.log combined
ServerSignature On
</VirtualHost>
Por supuesto, podemos crearnos todos los sitios virtuales que queramos. Sobre todo uno de desarrollo es fundamental para ir probando todas las cosas nuevas que queramos implementar sin que sean visibles antes de que estén acabadas.
Poniendo en marcha la nueva configuración
Cuando hagamos cualquier cambio a los ficheros de configuración de Apache y queramos que tengan efecto interrumpiendo de forma mínima el servicio, tenemos que tener la precaución de chequear que están correctos:
# apache2ctl configtest
Syntax OK
Porque si la sintaxis no fuera correcta o hubiera cualquier otro error:
# apache2ctl configtest
Syntax error on line 1 of /etc/apache2/sites-enabled/000-default:
Invalid command 'ZerverName', perhaps misspelled or defined by a module not included in the server configuration
…y no lo hemos verificado antes, el servidor no arrancará y tendremos el servicio parado hasta que consigamos arreglar el error:
# apache2ctl restart
Syntax error on line 1 of /etc/apache2/sites-enabled/000-default:
Invalid command 'ZerverName', perhaps misspelled or defined by a module not included in the server configuration
Además, el “apache2ctl restart” mata las conexiones que estuvieran activas en ese momento. Es por eso que es mucho más respetuoso con nuestros visitantes hacer un “apache2ctl graceful“, que espera a que todos los servidores activos acaben antes de reiniciar. Por tanto, para releer la configuración de Apache cuando la cambiemos, haremos:
# apache2ctl configtest
Syntax OK
# apache2ctl graceful
No debemos olvidar revisar frecuentemente los posibles errores que puedan aparecer en los logs para asegurarnos de que no haya ningún problema de configuración o que estemos sufriendo algún tipo de ataque.
MaxClients
En casos de avalanchas de visitas nos encontraremos con que ni la CPU, ni la memoria son nuestro cuello de botella sino, evidentemente, el ancho de banda de subida. Pero en esos casos, si nos entran muchísimas conexiones de diferentes clientes al mismo tiempo, el servidor sí que puede llegar a tener problemas de memoria porque tiene las conexiones abiertas y por el ancho de banda no se están sirviendo. Es por ello que yo descubrí que bajando el número máximo de clientes que se pueden atender (MaxClients) en el apache2.conf de los 150 de por defecto a 50, en casos de avalancha, la máquina no se agobiaba y a aquellos clientes que aceptaba, les servía más o menos correctamente. Había muchos que no eran aceptados, eso sí, pero que en cualquier caso, por el ancho de banda no se les podía haber servido en condiciones, así que mejor rechazarlos desde el principio y así desahogar al servidor:
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 50
MaxRequestsPerChild 0
</IfModule>
Tenemos mucha más información sobre cómo configurar Apache en la página de documentación de Apache 2.2.
Moderación con el tamaño de lo que publicamos
Y es precisamente por la limitación de ancho de banda que debemos de ser contenidos en lo que publicamos en nuestra web. Por ejemplo, una imagen de 300KiB que se muestre en todas las página de nuestro sitio puede suponer una verdadera bofetada a nuestros visitantes que tendrán que esperar segundos y segundos a que la página acabe de cargar… y eso si finalmente esperan y no la cierran antes. Por eso, cuidado con lo que hospedamos y seamos muy tacaños con el escaso ancho de banda con el que contamos. Antes hacía referencia a entradas previas que trataban de la compresión y cacheo de las páginas web. Con dicha técnica podremos reducir al mínimo el volumen de los ficheros HTML, CSS y JavaScript, pero el objetivo de mantener a un tamaño razonable las imágenes no debe de perderse nunca de vista.
Un poco de SEO para ahorrar ancho de banda
Unos visitantes tan pesados como necesarios son los robots de los buscadores. Los necesitamos para existir en Internet, pero sus visitas constantes consumen ancho de banda y no poco, ya que recordemos que recorren periódicamente toda nuestra web. Una solución para aliviar el problema es usar un fichero robots.txt y bloquear todo aquello que no necesitemos que sea encontrado. En el caso de un blog, podemos bloquear las páginas de categorías, las de etiquetas, los archivos… al fin y al cabo, es sólo contenido duplicado que lo único que puede hacer es confundir al buscador a la hora de decidirse por la mejor página. Pero la jugada maestra para ahorrar ancho de banda es prohibir a los buscadores que indexen las imágenes de nuestro sitio (Remove an image from Google Image Search). La gente que busca imágenes, raramente estará interesada por el contenido de nuestra página en sí mismo. Por ello, prohibiendo la búsqueda de imágenes, evitamos por un lado el gasto de ancho de banda de servir nuestras imágenes a los buscadores de imágenes y por otro, el de aquellos que acceden a nuestra página buscando imágenes, e incluso el de aquellos que, una vez encontrada la imagen que buscaban, decidan hacer hotlinking a nuestra imagen. Otra cosa es que te pueda interesar mucho el tráfico proveniente de buscadores de imágenes. En mi caso, el número de visitas procedente de images.google.com llegó a ser muy alto hasta que prohibí la búsqueda de imágenes en mi sitio, ya que analizando las búsquedas origen de las visitas, llegue a la conclusión de que no eran visitantes interesados en el contenido de mis páginas.
Si tenemos un feed por RSS o Atom, tenemos que tener en cuenta que los diferentes agregadores de noticias suelen acceder con cierta frecuencia para ver si hay nuevas entradas, así que puede ser muy útil para ahorrar ancho de banda servir el feed a través FeedBurner de forma que FeedBurner sea el único que acceda a nuestro feed y que sea él el que use su ancho de banda para alimentar al resto de agregadores.
Para analizar los logs, Debian nos ofrece varias aplicaciones ya preempaquetadas: Visitors, WebDruid, AWFFull y el veterano wwwstat.
Apache HTTP server benchmarking tool
Por último, no podemos dejar de mencionar el ab (Apache HTTP server benchmarking tool), una utilidad incluida en el paquete apache2-utils con la que podremos hacerle pruebas de carga a nuestro servidor web. Puede resultarnos útil para comparar el rendimiento de un Apache 1.3 con el de un Apache 2.2 o con el de un lighttpd o para probar las mejoras de la caché o de la compresión o para estudiar las consecuencias que los cambios en el código pueden suponer (por ejemplo, tras introducir un trozo de código PHP muy complejo de ejecutar y que tal vez resulte muy lento).
En esta prueba de ejemplo, le lanzo a mi servidor a través de la LAN peticiones de 5 en 5 (-c 5) durante un tiempo máximo de 60 segundos (-t 30), y veo que es capaz de atender 23 peticiones (los fallos “Length: 21” son porque las páginas devueltas no tienen todas el mismo tamaño, algo que no es un problema en este caso), pero que algunas han tenido que esperar hasta 40 segundos:
sigue en la parte #2
Si te gusta dame puntos
Hay otra parte... La #2
Si de lo que estamos hablando es de alojar un blog, la realidad es que tanto WordPress.com como Blogger dan un servicio gratuito excelente. WordPress.com (que no hay que confundir con el CMS WordPress, alojado en WordPress.org) lo hace a cambio de publicidad que muestran muy poco a menudo y no permiten que nosotros pongamos nuestra propia publicidad. Blogger sí que permite incluir anuncios de AdSense. A mí personalmente me desagradan los anuncios de AdSense, pero entiendo que éste pueda ser un factor importante a la hora de alojar nuestro blog en un sitio o en otro. Si queremos tener el blog en un dominio propio, WordPress.com nos lo permite por tan sólo 10$ al año, y Blogger también lo permite gratis (por supuesto, el coste de la compra del dominio va aparte).
Para alojar páginas estáticas, Google Pages podría valernos perfectamente.
Para tener e-mail, alojar páginas estáticas o almacenar documentos con nuestro propio dominio, Google Apps nos lo pone muy fácil. Además, Google recientemente ha añadido a la lista de aplicaciones de Google Apps el Google Sites, que nos permitirá tener un Structured Wiki también en nuestro propio dominio.
Si nada de lo anterior nos satisface por completo por falta de versatilidad para lo que queremos hacer, un hosting puede ser razonablemente barato. No soy la persona más indicada para recomendar uno, pero por ejemplo, SigT, un blog cuyo criterio se puede tener muy en cuenta, está en Dreamhost, y no parece que estén descontentos, aunque pueden contarnos algunas batallitas. Iñaki Silanes también se pasó hace poco a Dreamhost. El plan estándar de Dreamhost, que incluye SSH y 5TB de transferencia mensual, sale por 10.95$/mes si contratamos un mes, 9.95$/mes si contratamos un año, 7.95$/mes si contratamos 3 años y 5.95$/mes si contratamos 10 años. Yo llevo poco tiempo en 1and1.es y no tengo ninguna queja sobre ellos, pero en precio y características, definitivamente no son competitivos comparando con Dreamhost.
Además, tener un ordenador siempre encendido en casa no es exactamente gratis: además de la electricidad que gasta, sus componentes se van desgastando, sobre todo el disco duro, y si tenemos que reemplazar un disco duro, por menos de unos 60€ seguramente no lo podamos hacer.
El HC tiene muchas otras desventajas, entre las que podemos citar:
Intervalos sin servicio.
Poco ancho de banda de subida.
Según el servidor usado, es posible que tengamos poca velocidad de respuesta y las páginas dinámicas no se generen rápidamente.
Poca capacidad de respuesta ante picos inesperados de tráfico.
Disponibilidad reducida del ordenador que usemos como servidor para otras tareas.
Disponibilidad reducida del ancho de banda del que dispongamos para otras tareas (p.e. P2P).
No es lo más recomendable tener un dispositivo eléctrico 24×7 encendido: Aunque no es lo más probable, el cable se podría calentar, derretir, generar un cortocircuito y causar un incendio.
Preocupación por si el servicio se está dando correctamente.
¿Qué haces con el servidor cuando te vas a ausentar de casa por un espacio prolongado de tiempo?
¿Cómo reaccionar rápidamente ante una avería hardware?
¿Qué haces si se va la luz?
Es necesario invertir tiempo en la administración del servidor.
¡Uy! ¡Que mal lo hemos pintado! ¿Y no tiene ninguna ventaja el HC? Pues sí, hay una y muy grande, que puede compensar con creces todos los inconvenientes anteriores:
–== APRENDER ==–
¡Y así es! Porque del HC, lo más provechoso es lo que se aprende de las tecnologías web. Con él podremos ver cómo configurar Apache, cómo reparar nuestras bases de datos MySQL, cómo mantener nuestro sistema estable para tener que hacer el mínimo número de paradas posible, cómo crearnos scripts para tener todos los aspectos de nuestro servidor monitorizados y controlados, cómo estudiar los logs, cómo… ¡administrar un servidor web de verdad que sirve páginas de verdad!
En mi caso, además, que uso WordPress, el hosting casero me ha permitido hacer lo que he querido con él. He modificado el código como me ha parecido y he instalado los plugins que me han parecido útiles sin las restricciones de WordPress.com. Gracias a eso, también he aprendido un poco de PHP.
Bueno, ¿qué has pensado? ¿Sigues queriendo montar tu propio HC? ¡Pues sigue leyendo!
El servidor
¡No, no, no! No puedes usar tu nuevo y flamante Quad-Core con 8GB de RAM, una NVidia 8800GTX, 4 discos en RAID y fuente de 1000W como servidor de HC. Estoy de acuerdo que ninguno mejor que ese generará las páginas dinámicas y hará volar al Apache pero: ¿No es ese el ordenador que vas a usar para todo lo demás? ¿Con ese pedazo de tarjeta de vídeo no vas a usarlo para algún juego 3D? ¿Seguro que lo reiniciarás lo justo? ¿Tú te has dado cuenta del ruido que hacen sus ventiladores? Además, el precio del kWh es de unos 0.09 ceńtimos de €, así que a poco que consuma 300W, estamos hablando de 300x24x365x0.09/1000=236€ al año (o 19€ al mes).
Sí, ese Pentium III/4/AMD K7 que tienes ahí parado desde hace meses y que no sabes bien qué hacer con él te podría servir, pero apostaría sin dudarlo mucho a que también consume lo suyo y a que hace incluso más ruido que el nuevo. Es una buena opción, y si no te importa mucho el consumo eléctrico, definitivamente podría ser lo que necesitamos. Sin embargo, recordemos que tu casa es ese sitio al que vas después de un duro día y donde esperas encontrar paz, tranquilidad y el descanso del guerrero. Llegar y encontrarte ese odioso ordenador haciendo ruido un día y otro, y otro también y sin que te puedas permitir apagarlo, quizás no es lo que más te apetezca. Sí, ya sé que tú tal vez ya tienes ese mismo ordenador muchos días encendido bajando cosas con aMule y con Bittorrent, pero de vez en cuando lo apagas, ¿no? ¡Ah! ¿Cómo? ¿Que noooooo?
Bueno, a lo que quería llegar, es que a menos que tengáis una casa de 200m2 con una habitación por ahí perdida donde encerrar el ordenador bajo llave para no oírlo, seguramente necesitéis otra cosa. Si lo que queremos es el servidor perfecto para un HC profesional, válgame la contradicción, lo que nos hace falta es un ordenador de bajo consumo y sin ventiladores.
Hasta hace poco, los procesadores líderes indiscutibles en esta categoría eran los VIA C3 y C7, de los que he hablado extensamente en este blog. Las placas VIA EPIA de formato Mini-ITX han sido durante mucho tiempo elecciones excelentes para este propósito; los drivers para el procesador gráfico no son lo mejor del mundo, pero no es algo realmente importante si sólo la vamos a usar como servidor. Hay otros fabricantes que tienen placas con procesador integrado y chipset de VIA, como las Jetway, las eBox (distribuidas en España por EPATec) o la Elite C7VCM (con fuente de alimentación DC-DC integrada), todas ellas más baratas que las VIA EPIA, pero no creo que me equivoque mucho si digo que probablemente hay muchísima más documentación y experiencia sobre las VIA EPIA que sobre otros modelos (sin entrar en la teórica superior calidad de unas sobre otras).
Pero decía “hasta hace poco” porque Intel y AMD no están indiferentes ante este trozo de mercado de procesadores/placas sin ventilador y de bajo consumo. AMD hace tiempo que tiene los procesadores AMD Geode, aunque la verdad es que no han sido muy populares en el segmento de mercado de los procesadores VIA, tal vez porque hasta la salida del Geode NX, el rendimiento de sus predecesores era muy pobre (ejemplos de placas con AMD Geode: ALIX2C2, Albatron KI741CX).
Nota: Gracias a Tostadilla por varios de los enlaces.
Intel, por su parte, está a punto de descabalgar a sus competidores también en este segmento de mercado igual que ha hecho con AMD en los segmentos de procesadores para ordenadores de sobremesa y en procesadores para portátiles. Su nueva placa base D210GLY, con procesador de refrigeración pasiva Intel Celeron 215 (con arquitectura Core) a 1.2GHz, con un consumo equiparable a las VIA EPIA, y con un precio de 69.50$, es un misil directo a la línea de flotación de las VIA EPIA. Yo no he probado una de estas placas, pero dado el historial de productos de calidad de Intel y su compromiso con la creación de drivers de código abierto, no dudaría ni un momento en recomendar una de estas placas por delante de las de VIA. Por no decir que seguro que a igualdad de frecuencia de reloj, uno de estos Celeron tiene mucho más rendimiento que uno de VIA. Josemanu de La Factoría Secreta acaba de cambiar su VIA EPIA por una de estas placas… ¡a ver qué nos va contando sobre ella!
Respecto a otros aspectos del servidor, sólo cabría mencionar la memoria RAM y tal vez el disco duro, pero como cualquier tamaño de disco duro superior a los 10GB será más que suficiente para casi cualquier propósito, quizás lo más determinante pueda ser la RAM. En mi opinión, una cantidad razonable de RAM para manejar con soltura varias peticiones de Apache y el MySQL son 512MB, pero 256MB podrían ser suficientes.
Para finalizar la sección, comentar que un portátil definitivamente no es una opción como servidor. Pero ni como servidor de HC ni para tenerlo siempre encendido con programas P2P. Un portátil es un portátil. No están preparados en absoluto para un estado de sobrecalentamiento permanente y a sus pequeños discos duros de 2.5″ no les gusta que les tengan permanentemente dando vueltas y estarán condenados con mucha probabilidad a una muerte prematura si les obligas a ello.
Y no se me olvidan los dispositivos de ultra-bajo-consumo que aceptan Linux, como el NSLU2, el LinkStation, la KuroBox o la EFIKA. Aunque se les pueda instalar Linux, en mi opinión no dan la talla para un servidor web completo como el que nos ocupa.
Por cierto, Intel está a punto de revolucionar aún más el panorama de los procesadores de bajo consumo con la llegada de los Ultra-Mobile PC (UMPC) y sus procesadores: A100/A110 y su reciente Atom (via Blog Staredsi).
El proveedor de Internet
Evidentemente, necesitaremos un acceso de banda ancha a Internet, y con este acceso llegará nuestra mayor limitación: el ancho de banda de subida. El acceso de banda ancha más común actualmente en España es el ADSL de 3Mbps de bajada y de 320kbps de subida. La bajada nos importa bien poco, pero la subida es lo que definitivamente determinará el máximo número de usuarios que podremos atender simultáneamente con una cierta fluidez.
Esos 40KB/s teóricos de subida pueden parecer poco, pero no son desdeñables, ya que pueden suponer una transferencia máxima mensual teórica de más de 100GB, bastante superior a lo que ofrecen muchos hostings:
320x3600x24x31/8/106=107GB
1KB=103Bytes, 1GB=106Bytes
Sin embargo, evidentemente, esta no es una comparación del todo justa, ya que no podemos esperar que el flujo de visitas sea regular, sino que la naturaleza de la web nos trae precisamente lo contrario; exceptuando el tráfico procedente de los buscadores que tal vez sí sea razonablemente uniforme, las visitas normalmente las tendremos a rachas: a ciertas horas del día, cuando se nos cita y enlaza desde otras páginas o cuando publicamos algo nuevo. Si se nos amontonan las visitas, las páginas tardarán considerablemente más en ser descargadas y la experiencia del usuario en nuestra página podría llegar a ser muy pobre, …y eso si no se cansa de esperar y definitivamente la cierra sin que acabe de cargarse.
Por tanto, ¿son suficientes esos 40KB/s para dar un servicio razonable? En mi experiencia, en principio, sí, pero vamos a tener que ser cuidadosos con el material que servimos y tenemos que tener bien claro que ante un pico brutal de visitas, vamos a fracasar sin remedio.
Por supuesto, no sólo existe la oferta de los 320kbps de subida. Ahora mismo también hay otras compañías de ADSL que ofrecen hasta 1Mbps de subida (con sus “hasta” 20Mbps de bajada). Sin embargo, cuando en algún momento me he planteado contratar alguna de esas alternativas, siempre me he encontrado docenas de mensajes en los foros de personas quejándose de cortes y microcortes frecuentes y reiterados que me han desanimado. Al final, la calidad de una de estas líneas con ADSL 2+ dependerá del ruido de la línea y de la distancia del par de cobre hasta la central telefónica, pero en el mejor de los casos, su calidad parece claramente insuficiente si queremos dar un servicio de la forma más estable posible.
Por otra parte, el panorama parece que va a mejorar mucho y muy pronto. ONO ya ofrece 1Mbps de subida, que tal vez sean más estables que los del ADSL 2+ y la aparición del VDSL2 de la mano de Telefónica es inminente, al mismo tiempo que se acerca el FTTH.
Otro aspecto que podemos plantarnos es la conveniencia de la IP fija. En Telefónica sale por 12€ al mes, y nos podría facilitar enormemente muchos aspectos del HC. Sin embargo, sólo por lo que cuesta, podríamos contratar un hosting profesional, de modo que es una opción que la mayoría descartaríamos.
El dominio
Por supuesto, vamos a necesitar uno o más dominios para hacer realidad nuestro proyecto. Si tuviéramos una IP fija, podríamos comprar un dominio a cualquier registrador y hacer que el DNS apuntara a nuestra IP fija. En nuestro servidor tendríamos que configurar un servidor de DNS además de todos los otros servicios que quisiéramos proporcionar.
Sin embargo, con una IP dinámica también podremos montar nuestro HC sin problemas gracias a empresas como DynDNS o no-ip.com. En ¿Piensas en si un día te roban el portátil? ya vimos una introducción a cómo funcionan estos servicios y una guía de configuración del ddclient en Debian para que actualice la IP tan pronto como ésta cambie. Suponiendo dicha teoría sabida, vamos a ver cómo ajustar la configuración de DynDNS al entorno de un HC como el que estamos montando.
DynDNS pone a nuestra disposición un gran número de dominios base sobre el que crear hostnames (hasta 5 por cuenta) como por ejemplo:
barriosesamo.homelinux.org
gustavo.blogsite.org
supercoco.is-a-geek.org
Los dominios disponibles tienen nombres bastante útiles y llamativos, de forma que resulta bastante fácil encontrar una combinación que sea de nuestro agrado. La mía, como los más viejos del lugar saben, fue y es valencia.homelinux.org. Si queremos asociar una IP dinámica a un dominio propio, podemos considerar la opción de comprar el servicio Custom DNS, que sale por 27.5$ al año. Si también compramos el dominio en DynDNS, por ejemplo, uno .com por 15$, al hacer la compra conjunta con el Custom DNS nos hacen un descuento de 5$. Por tanto, la broma de Custom DNS + Dominio nos saldrá por 37.5$/año. En DynDNS no podemos comprar un dominio .es, pero si lo compramos en otro sitio, podemos hacerlo funcionar con el servicio Custom DNS de DynDNS.
Yo compré el dominio vicente-navarro.com con el servicio Custom DNS y la configuración del ddclient para actualizar puntualmente ambos dominios era (/etc/ddclient.conf):
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
pid=/var/run/ddclient.pid
protocol=dyndns2
use=web, web=checkip.dyndns.org/, web-skip='IP Address'
wildcard=yes
server=members.dyndns.org
login=supercoco
password=contrasenyadesupercoco
valencia.homelinux.org
custom=yes, vicente-navarro.com
Como vemos, la única diferencia entre actualizar un hostname de los gratuitos y uno de los Custom DNS es la cadena custom=yes. www.vicente-navarro.com puede ser un CNAME a vicente-navarro.com o podría ser un hostname diferente, en cuyo caso tendríamos que añadir una línea adicional en el ddclient.conf.
La línea:
use=web, web=checkip.dyndns.org/, web-skip='IP Address'
sirve para especificarle al ddclient dónde encontrar la IP a usar para actualizar el servidor de DNS. Poniendo use=web le decimos que acceda a una web (en este caso checkip.dyndns.org) para consultarla. Si nuestro servidor tuviera directamente la IP pública de Internet en uno de sus interfaces, algo cada vez más raro hoy en día, podríamos poner algo así:
use=if, if=eth0
El ddclient es capaz de conectarse a ciertos routers de diferentes formas para obtener la dirección directamente del router. Podemos consultar todas las posibilidades en la documentación del ddclient.
Para probar el correcto funcionamiento del ddclient, es una buena idea usar la opción -v y la -force también puede ser necesaria para hacer troubleshooting ya que el cliente se niega a enviar una actualización al servidor de DNS si la IP no ha cambiado (lo sabe por la caché que mantiene en /var/cache/ddclient/ddclient.cache):
# ddclient -v -force
CONNECT: checkip.dyndns.org
CONNECTED:
SENDING: GET / HTTP/1.0
SENDING: Host: checkip.dyndns.org
SENDING: User-Agent: ddclient/3.6.7
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Content-Type: text/html
RECEIVE: Server: DynDNS-CheckIP/1.0
RECEIVE: Connection: close
RECEIVE: Cache-Control: no-cache
RECEIVE: Pragma: no-cache
RECEIVE: Content-Length: 105
RECEIVE:
RECEIVE: <html><head><title>Current IP Check</title></head><body>Current IP Address: 81.39.245.141</body></html>
INFO: forcing update of valencia.homelinux.org.
INFO: forcing update of vicente-navarro.com.
INFO: setting IP address to 81.39.245.141 for valencia.homelinux.org
UPDATE: updating valencia.homelinux.org
CONNECT: members.dyndns.org
CONNECTED:
SENDING: GET /nic/update?system=dyndns&hostname=valencia.homelinux.org&myip=81.39.245.141&wildcard=ON HTTP/1.0
SENDING: Host: members.dyndns.org
SENDING: Authorization: Basic dmluYWpvOmxhZW5jb250cmFzdGU6LSk=
SENDING: User-Agent: ddclient/3.6.7
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Date: Sat, 08 Mar 2008 10:12:15 GMT
RECEIVE: Server: Apache
RECEIVE: X-UpdateCode: n
RECEIVE: Content-Type: text/plain
RECEIVE: Connection: close
RECEIVE:
RECEIVE: good 81.39.245.141
SUCCESS: updating valencia.homelinux.org: good: IP address set to 81.39.245.141
INFO: setting IP address to 81.39.245.141 for vicente-navarro.com
UPDATE: updating vicente-navarro.com
CONNECT: members.dyndns.org
CONNECTED:
SENDING: GET /nic/update?system=custom&hostname=vicente-navarro.com&myip=81.39.245.141&wildcard=ON HTTP/1.0
SENDING: Host: members.dyndns.org
SENDING: Authorization: Basic dmluYWpvOmxhZW5jb250cmFzdGU6LSk=
SENDING: User-Agent: ddclient/3.6.7
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Date: Sat, 08 Mar 2008 10:12:15 GMT
RECEIVE: Server: Apache
RECEIVE: X-UpdateCode: n
RECEIVE: Content-Type: text/plain
RECEIVE: Connection: close
RECEIVE:
RECEIVE: good 81.39.245.141
SUCCESS: updating vicente-navarro.com: good: IP address set to 81.39.245.141
En el fichero /etc/default/ddclient podemos especificar si queremos que ddclient funcione como un demonio, que es lo recomendable (otra opción es planificar el ddclient en el cron) y cada cuánto tiempo debería de chequear si ha habido un cambio de IP (5 minutos por defecto, si lo ponemos más frecuente, es posible que nos denieguen el acceso por abuso del servicio):
# Configuration for ddclient scripts
# generated from debconf on Sat Mar 10 13:45:30 CET 2007
#
# /etc/default/ddclient
# Set to "true" if ddclient should be run every time a new ppp connection is
# established. This might be useful, if you are using dial-on-demand
run_ipup="false"
# Set to "true" if ddclient should run in daemon mode
run_daemon="true"
# Set the time interval between the updates of the dynamic DNS name in seconds.
# This option only takes effect if the ddclient runs in daemon mode.
daemon_interval="300"
Por tanto, cada vez que el ISP nos cambie la IP (algo que normalmente no ocurre en semanas) nos encontraremos con que tendremos unos pocos minutos sin servicio. Otra opción, la óptima, es que nuestro router soporte el protocolo de DynDNS y sea capaz de actualizar el servidor de DNS cada vez que detecte un cambio de IP en la interfaz de WAN. Mi Zyxel 660HW lo soporta, por lo que sí que es capaz de actualizar un hostname como valencia.homelinux.org, pero no es capaz de gestionar hostnames de dominios Custom DNS por defecto:
ynDNS mantiene una lista de dispositivos hardware con un cliente DynDNS integrado certificado. El popular Linksys WRT54G es uno de ellos y soporta Custom DNS poniendo una coletilla al nombre del dominio: example.com&system=custom. De todas formas, DynDNS prefiere los clientes software.
Para finalizar, podemos comentar la lista de servicios que ddclient soporta según su README, por si preferimos uno alternativo a DynDNS:
Dynamic DNS services currently supported include:
DynDNS.org - See http://www.dyndns.org for details on obtaining a free account.
Hammernode - See http://www.hn.org for details on obtaining a free account.
Zoneedit - See http://www.zoneedit.com for details.
EasyDNS - See http://www.easydns.com for details.
NameCheap - See http://www.namecheap.com for details
El sistema operativo
A estas alturas, nadie se puede sorprender de que yo recomiende como sistema operativo de nuestro servidor de HC la última versión estable de Debian (en estos momentos la Debian Etch 4.0) con sus correspondientes actualizaciones de seguridad. Las versiones estables de Debian tienen mucha fama por su gran estabilidad a costa de llevar versiones menos recientes pero mucho más probadas. Cuando me pasé a 1and1.es, una de las agradables sorpresas que me llevé fue ver que usaban Debian en sus servidores.
Hace unas semanas, cuando se hizo público el famoso exploit que afectaba a casi todas las versiones del kernel, el equipo de seguridad de Debian se apuntó un buen tanto al ser la primera en distribuir un parche de seguridad para el problema. Pero de todas formas, cualquier distribución de Linux bien mantenida, estable y con constantes actualizaciones de seguridad es perfectamente válida para nuestro propósito.
Y eso sin querer hacer un desprecio a las diferentes *BSD, que pueden ser una opción tanto o más buena que cualquier Linux, quizás destacando OpenBSD por su foco en la seguridad.
Y Windows… pues bueno, se podría tener un servidor de HC con Windows, pero las posibilidades de gestión y actualización remota se reducirían drásticamente. Definitivamente, no es la mejor opción.
El router
En la mayoría de los casos, nuestro servidor de HC estará detrás de un router que será el que tenga la IP pública del interfaz de WAN y que distribuirá el tráfico entre los equipos conectados a la LAN. Además, no es que sea lo más típico, es que a menos que el servidor de HC sea el único sistema que vaya a acceder a Internet en la casa, tampoco existe otra opción válida.
El router tenemos que configurarlo para que nuestro servidor de HC siempre reciba la misma dirección IP por DHCP, algo que la mayoría de routers soportan asociando una dirección MAC determinada con una misma IP. Otra opción es configurar el servidor para que use una IP fija y no la obtenga por DHCP, opción más segura que la primera, pero tendremos que usar una IP fuera del rango de direcciones DHCP que concede el router aunque dentro de la misma subred.
Además, tendremos que abrir como mínimo el puerto 80 y configurar el NAT para que las peticiones a dicho puerto vayan a la IP que hemos asignado a nuestro servidor. Otro puerto fundamental es el 22 para permitir el acceso por SSH y así poder hacer mantenimiento remoto del servidor. Opcionalmente, podemos abrir el 25 para SMTP y tal vez el 110 (POP3) y el 143 (IMAP).
Los sistemas de la LAN distintos al servidor probablemente no podrán usar el servidor de nombres de Internet para acceder a los servicios que proporciona el servidor (por ejemplo, para ver nuestra página web desde otro sistema de la red), porque el dominio resuelve a una IP que tiene el router, por lo que le estaremos mandado las peticiones al router, no al servidor de HC. Es por ello que, o montamos un pequeño DNS que dé servicio a la LAN, o introducimos en el fichero /etc/hosts de todos los sistemas (incluso en los Windows en c:windowssystem32driversetchosts) una referencia a los hostnames de todos los servicios que tengamos hospedados:
192.168.1.30 www.vicente-navarro.com vicente-navarro.com
192.168.1.30 valencia.homelinux.org
Para finalizar, una advertencia sobre el Wi-Fi y su inconveniencia para nuestro propósito. Nuestro servidor de HC debería estar conectado por cable al router. La conexión Wi-Fi, aunque nos pueda parecer que normalmente es muy estable, está sujeta a muchas interferencias sobre las que no tenemos control. Y de entre esas interferencias, yo destacaría la de los vecinos. En mi casa, por ejemplo, yo detecto multitud de señales Wi-Fi diferentes de vecinos que me provocan graves interferencias y que ni siquiera me permiten recibir la señal del router en otra habitación por muchos cambios de canal que pruebe, por lo que me tuve que cablear la casa. Otros casos pueden ser menos graves, pero en cualquier momento puedes encontrarte con que la señal del vecino causa interrupciones en la tuya. Definitivamente, no parece lo más conveniente.
El servidor web
Hablar de servidor web en un sistema UNIX es casi sinónimo de hablar de Apache. Siempre quise probar el lighttpd, pero nunca llegué a ponerme manos a la obra, así que no puedo contar de primera mano qué tal funciona en un sistema modesto como el mío, pero en general, tiene muy buena prensa, especialmente en lo que toca a consumo de memoria. En la gráfica de Febrero de Netcraft, vemos que lighttpd ya va haciéndose ver con su millón y medio de sitios que lo usan. Creo que es un candidato excelente como servidor web para nuestro HC.
Volviendo a Apache, todas las distribuciones tienen un paquete de Apache perfectamente listo para instalar y comenzar a trabajar; cada una con sus peculiaridades de configuración. Lo primero que tendremos que elegir es si queremos Apache 1.3 o Apache 2.x, un viejo debate en el que yo no me atrevo a entrar. Para el desarrollo de Apache 2.0 se reescribió la mayor parche del código y su mayor novedad fue que funcionaba con threads UNIX. Aunque su rendimiento es mejor en general, su adopción ha sido muy lenta porque muchos de los módulos existentes para Apache 1.3 no existían en Apache 2.x y porque la documentación de PHP desaconsejaba usarlo. En la actualidad, las instrucciones de instalación de PHP en entornos con Apache 2 muestran la siguiente advertencia:
Warning
We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM
En Debian tenemos paquetes para Apache 1.3 y para Apache 2.2. En el caso de Apache 2, con distintas posibilidades de MPM (Multi-Processing Module):
apache - versatile, high-performance HTTP server
apache-common - support files for all Apache webservers
apache-dbg - debug versions of the Apache webservers
apache-dev - development kit for the Apache webserver
apache-doc - documentation for the Apache webserver
apache-perl - versatile, high-performance HTTP server with Perl support
apache-ssl - versatile, high-performance HTTP server with SSL support
apache2 - Next generation, scalable, extendable web server
apache2-doc - documentation for apache2
apache2-mpm-event - Event driven model for Apache HTTPD 2.1
apache2-mpm-itk - multiuser MPM for Apache 2.2
apache2-mpm-perchild - Transitional package - please remove
apache2-mpm-prefork - Traditional model for Apache HTTPD 2.1
apache2-mpm-worker - High speed threaded model for Apache HTTPD 2.1
apache2-prefork-dev - development headers for apache2
apache2-src - Apache source code
apache2-threaded-dev - development headers for apache2
apache2-utils - utility programs for webservers
apache2.2-common - Next generation, scalable, extendable web server
El paquete apache2-mpm-prefork es el que necesitamos según la documentación de PHP (Apache MPM prefork). Si miramos su descripcción, vemos que permite usar Apache 2 de una forma similar a la que funcionaba Apache 1.3 evitando problemas con librerías que no son thread-safe a cambio de algo de rendimiento:
$ apt-cache show apache2-mpm-prefork
[...]
Description: Traditional model for Apache HTTPD 2.1
This Multi-Processing Module (MPM) implements a non-threaded,
pre-forking web server that handles requests in a manner similar to
Apache 1.3. It is appropriate for sites that need to avoid threading for
compatibility with non-thread-safe libraries. It is also the best MPM
for isolating each request, so that a problem with a single request will
not affect any other.
.
It is not as fast, but is considered to be more stable.
[...]
Y, de hecho, podemos comprobar que es un prerequisito para instalar el mod-php5:
$ apt-cache show libapache2-mod-php5
[...]
Depends: libbz2-1.0, libc6 (>= 2.3.6-6), libcomerr2 (>= 1.33-3), libdb4.4, libkrb53 (>= 1.4.2),
libpcre3 (>= 4.5), libssl0.9.8 (>= 0.9.8c-1), libxml2 (>= 2.6.27), zlib1g (>= 1:1.2.1),
mime-support (>= 2.03-1), apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-itk,
apache2.2-common, php5-common (= 5.2.0-8+etch10), libmagic1, ucf
[...]
Los diferentes paquetes apache2-mpm-* lo que hacen es instalar un binario principal de Apache diferente:
$ dpkg -L apache2-mpm-prefork | egrep 'bin|lib'
/usr/sbin
/usr/sbin/apache2
El módulo de MPM que Debian instala por defecto si hacemos un simple “apt-get install apache2” es el apache2-mpm-worker (Apache MPM worker), pero si instalamos el mod-php5, es reemplazado por el apache2-mpm-prefork.
En definitiva, para instalar con un sólo comando un sistema LAMP (Linux+Apache+MySQL+PHP) en Debian, sólo necesitaremos ejecutar el siguiente comando:
# apt-get install apache2 libapache2-mod-php5 php5-mysql mysql-server-5.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]
The following NEW packages will be installed:
apache2 apache2-mpm-prefork apache2-utils apache2.2-common libapache2-mod-php5 libdbd-mysql-perl
libdbi-perl libmysqlclient15off libnet-daemon-perl libplrpc-perl libterm-readkey-perl mysql-client-5.0
mysql-common mysql-server-5.0 php5-common php5-mysql
[...]
Las versiones de Debian Etch son razonablemente recientes: Apache 2.2, MySQL 5.0 y PHP 5. Creo que en un sistema que montamos a nuestro gusto para aprender, tampoco vale la pena irnos a las versiones más viejas. Los hostings profesionales ya son bastante rácanos en cuanto al uso de versiones modernas (¡hace poco me encontré con uno que aún usaba MySQL 3!), como para que nosotros les emulemos. Si la versión es estable para Debian, también lo es para mí.
Por tanto, una vez que tenemos el Apache 2.2 instalado, en Debian tenemos un fichero de configuración global en /etc/apache2/apache2.conf. Desde ese fichero se incluye el /etc/apache2/httpd.conf, que por defecto está vacío y preparado para que nosotros introduzcamos nuestras líneas de configuración personalizadas sin tener que alterar el principal. En el fichero ports.conf se especifica el puerto a usar, por defecto el 80. Luego tenemos los directorios de /etc/apache2/:
mods-available/
mods-enabled/
sites-available/
sites-enabled/
En el mods-available tenemos los módulos instalados en el sistema. En el sites-available tenemos todos los sitios virtuales configurados en el sistema. En los directorios mods-enabled y sites-enabled tenemos enlaces a los módulos y sitios virtuales que queremos habilitar. En las entradas de compresión y cacheo de Apache vimos cómo habilitar y configurar los módulos:
Probando el mod_deflate de Apache
Usando el mod_cache de Apache para que el mod_deflate no incremente la carga del servidor
Los enlaces los podemos crear y eliminar a mano o con las siguientes herramientas de Debian:
a2dismod a2dissite a2enmod a2ensite
Tenemos más información sobre los aspectos particulares de configuración de Apache en Debian en el fichero /usr/share/doc/apache2.2-common/README.Debian.
Configuración de los sitios virtuales
Por defecto, Debian sólo nos deja un sitio virtual configurado en /etc/apache2/sites-available/default que es el que por defecto se usa cuando se accede con un hostname que no tiene una configuración de sitio virtual específica. Tiene el directorio base de documentos en /var/www/apache2-default/ y nos permite recorrer la documentación del servidor sólo desde el navegador del propio servidor, http://localhost/doc/:
NameVirtualHost *
<VirtualHost *>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
RedirectMatch ^/$ /apache2-default/
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>
La configuración básica de sitio virtual que yo usaba (/etc/apache2/sites-available/vicente-navarro.com, con enlace en sites-enabled) era:
<VirtualHost *>
ServerName vicente-navarro.com
ServerAlias www.vicente-navarro.com
DocumentRoot /var/www/vicente-navarro.com/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/vicente-navarro.com/>
Options FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error_vn.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access_vn.log combined
ServerSignature On
</VirtualHost>
Sobre ella, podemos hacer algunos cambios:
Si queremos permitir la configuración con ficheros .htaccess, tendremos que quitar las líneas “AllowOverride None“.
Si queremos presentar un documento personalizado para errores 404, podemos incluir una línea como: “ErrorDocument 404 /404.php“.
Por otra parte, teniendo en cuenta que nuestro ancho de banda de subida es muy limitado, el hotlinking (enlace a las imágenes de nuestro sitio desde otro sitio) es especialmente dañino, por lo que deberíamos de prevenir hasta donde sea posible el “robo de imágenes”. Una buena forma de hacerlo es rechazando las peticiones cuyo referer no sea nuestra propia página o ninguno (hay firewalls que los eliminan, la extensión No-Referer de Firefox también los elimina, e incluso podemos controlarlo en Firefox con el parámetro Network.http.sendRefererHeader). How can I prevent people from “stealing” the images from my web site?:
SetEnvIf REFERER "vicente-navarro.com" linked_from_here
SetEnvIf REFERER "^$" linked_from_here
<FilesMatch ".(gif|jpg|png)">
Order deny,allow
Deny from all
Allow from env=linked_from_here
</FilesMatch>
Además, en mi caso, cuando cambié el dominio principal de valencia.homelinux.org a www.vicente-navarro.com, tuve que implementar una redirección 301, para lo que creé un sitio virtual en /etc/apache2/sites-available/valencia.homelinux.org:
<VirtualHost *>
ServerName valencia.homelinux.org
Redirect permanent / http://www.vicente-navarro.com/blog/
ErrorLog /var/log/apache2/error_vho.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access_vho.log combined
ServerSignature On
</VirtualHost>
Por supuesto, podemos crearnos todos los sitios virtuales que queramos. Sobre todo uno de desarrollo es fundamental para ir probando todas las cosas nuevas que queramos implementar sin que sean visibles antes de que estén acabadas.
Poniendo en marcha la nueva configuración
Cuando hagamos cualquier cambio a los ficheros de configuración de Apache y queramos que tengan efecto interrumpiendo de forma mínima el servicio, tenemos que tener la precaución de chequear que están correctos:
# apache2ctl configtest
Syntax OK
Porque si la sintaxis no fuera correcta o hubiera cualquier otro error:
# apache2ctl configtest
Syntax error on line 1 of /etc/apache2/sites-enabled/000-default:
Invalid command 'ZerverName', perhaps misspelled or defined by a module not included in the server configuration
…y no lo hemos verificado antes, el servidor no arrancará y tendremos el servicio parado hasta que consigamos arreglar el error:
# apache2ctl restart
Syntax error on line 1 of /etc/apache2/sites-enabled/000-default:
Invalid command 'ZerverName', perhaps misspelled or defined by a module not included in the server configuration
Además, el “apache2ctl restart” mata las conexiones que estuvieran activas en ese momento. Es por eso que es mucho más respetuoso con nuestros visitantes hacer un “apache2ctl graceful“, que espera a que todos los servidores activos acaben antes de reiniciar. Por tanto, para releer la configuración de Apache cuando la cambiemos, haremos:
# apache2ctl configtest
Syntax OK
# apache2ctl graceful
No debemos olvidar revisar frecuentemente los posibles errores que puedan aparecer en los logs para asegurarnos de que no haya ningún problema de configuración o que estemos sufriendo algún tipo de ataque.
MaxClients
En casos de avalanchas de visitas nos encontraremos con que ni la CPU, ni la memoria son nuestro cuello de botella sino, evidentemente, el ancho de banda de subida. Pero en esos casos, si nos entran muchísimas conexiones de diferentes clientes al mismo tiempo, el servidor sí que puede llegar a tener problemas de memoria porque tiene las conexiones abiertas y por el ancho de banda no se están sirviendo. Es por ello que yo descubrí que bajando el número máximo de clientes que se pueden atender (MaxClients) en el apache2.conf de los 150 de por defecto a 50, en casos de avalancha, la máquina no se agobiaba y a aquellos clientes que aceptaba, les servía más o menos correctamente. Había muchos que no eran aceptados, eso sí, pero que en cualquier caso, por el ancho de banda no se les podía haber servido en condiciones, así que mejor rechazarlos desde el principio y así desahogar al servidor:
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 50
MaxRequestsPerChild 0
</IfModule>
Tenemos mucha más información sobre cómo configurar Apache en la página de documentación de Apache 2.2.
Moderación con el tamaño de lo que publicamos
Y es precisamente por la limitación de ancho de banda que debemos de ser contenidos en lo que publicamos en nuestra web. Por ejemplo, una imagen de 300KiB que se muestre en todas las página de nuestro sitio puede suponer una verdadera bofetada a nuestros visitantes que tendrán que esperar segundos y segundos a que la página acabe de cargar… y eso si finalmente esperan y no la cierran antes. Por eso, cuidado con lo que hospedamos y seamos muy tacaños con el escaso ancho de banda con el que contamos. Antes hacía referencia a entradas previas que trataban de la compresión y cacheo de las páginas web. Con dicha técnica podremos reducir al mínimo el volumen de los ficheros HTML, CSS y JavaScript, pero el objetivo de mantener a un tamaño razonable las imágenes no debe de perderse nunca de vista.
Un poco de SEO para ahorrar ancho de banda
Unos visitantes tan pesados como necesarios son los robots de los buscadores. Los necesitamos para existir en Internet, pero sus visitas constantes consumen ancho de banda y no poco, ya que recordemos que recorren periódicamente toda nuestra web. Una solución para aliviar el problema es usar un fichero robots.txt y bloquear todo aquello que no necesitemos que sea encontrado. En el caso de un blog, podemos bloquear las páginas de categorías, las de etiquetas, los archivos… al fin y al cabo, es sólo contenido duplicado que lo único que puede hacer es confundir al buscador a la hora de decidirse por la mejor página. Pero la jugada maestra para ahorrar ancho de banda es prohibir a los buscadores que indexen las imágenes de nuestro sitio (Remove an image from Google Image Search). La gente que busca imágenes, raramente estará interesada por el contenido de nuestra página en sí mismo. Por ello, prohibiendo la búsqueda de imágenes, evitamos por un lado el gasto de ancho de banda de servir nuestras imágenes a los buscadores de imágenes y por otro, el de aquellos que acceden a nuestra página buscando imágenes, e incluso el de aquellos que, una vez encontrada la imagen que buscaban, decidan hacer hotlinking a nuestra imagen. Otra cosa es que te pueda interesar mucho el tráfico proveniente de buscadores de imágenes. En mi caso, el número de visitas procedente de images.google.com llegó a ser muy alto hasta que prohibí la búsqueda de imágenes en mi sitio, ya que analizando las búsquedas origen de las visitas, llegue a la conclusión de que no eran visitantes interesados en el contenido de mis páginas.
Si tenemos un feed por RSS o Atom, tenemos que tener en cuenta que los diferentes agregadores de noticias suelen acceder con cierta frecuencia para ver si hay nuevas entradas, así que puede ser muy útil para ahorrar ancho de banda servir el feed a través FeedBurner de forma que FeedBurner sea el único que acceda a nuestro feed y que sea él el que use su ancho de banda para alimentar al resto de agregadores.
Para analizar los logs, Debian nos ofrece varias aplicaciones ya preempaquetadas: Visitors, WebDruid, AWFFull y el veterano wwwstat.
Apache HTTP server benchmarking tool
Por último, no podemos dejar de mencionar el ab (Apache HTTP server benchmarking tool), una utilidad incluida en el paquete apache2-utils con la que podremos hacerle pruebas de carga a nuestro servidor web. Puede resultarnos útil para comparar el rendimiento de un Apache 1.3 con el de un Apache 2.2 o con el de un lighttpd o para probar las mejoras de la caché o de la compresión o para estudiar las consecuencias que los cambios en el código pueden suponer (por ejemplo, tras introducir un trozo de código PHP muy complejo de ejecutar y que tal vez resulte muy lento).
En esta prueba de ejemplo, le lanzo a mi servidor a través de la LAN peticiones de 5 en 5 (-c 5) durante un tiempo máximo de 60 segundos (-t 30), y veo que es capaz de atender 23 peticiones (los fallos “Length: 21” son porque las páginas devueltas no tienen todas el mismo tamaño, algo que no es un problema en este caso), pero que algunas han tenido que esperar hasta 40 segundos:
sigue en la parte #2
Si te gusta dame puntos
Hay otra parte... La #2