El blog de Vicente Navarro

Hosting casero HOWTO

En Primer aniversario del blog os contaba que este blog estuvo en un hosting casero durante un ao entero. Viendo los comentarios, parece que esto llam bastante la atencin y, de hecho, hubo unas cuantas peticiones de una entrada sobre el hosting casero (en adelante HC), as que, desde la mucha o poca autoridad que me da mi ao de autohospedaje, ah vamos: Realmente queremos tener un hosting casero? El servidor El proveedor de Internet El dominio El sistema operativo El router El servidor web Configuracin de los sitios virtuales Poniendo en marcha la nueva configuracin MaxClients Moderacin con el tamao de lo que publicamos Un poco de SEO para ahorrar ancho de banda Apache HTTP server benchmarking tool El servidor de correo Correo con nuestro propio dominio con Google Apps Otras cuestiones Backups El sistema de respaldo Los cortes de corriente Mantenimiento remoto P2P y hosting casero? Scripting Conclusin Realmente queremos tener un hosting casero? Echando la vista atrs, al HC yo le veo muchos ms inconvenientes que ventajas. Quizs 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 slo 10$ al ao, y Blogger tambin lo permite gratis (por supuesto, el coste de la compra del dominio va aparte). Para alojar pginas estticas, Google Pages podra valernos perfectamente. Para tener e-mail, alojar pginas estticas o almacenar documentos con nuestro propio dominio, Google Apps nos lo pone muy fcil. Adems, Google recientemente ha aadido a la lista de aplicaciones de Google Apps el Google Sites, que nos permitir tener un Structured Wiki tambin 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 ms 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 estn descontentos, aunque pueden contarnos algunas batallitas. Iaki Silanes tambin se pas hace poco a Dreamhost. El plan estndar 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 ao, 7.95$/mes si contratamos 3 aos y 5.95$/mes si contratamos 10 aos. Yo llevo poco tiempo en 1and1.es y no tengo ninguna queja sobre ellos, pero en precio y caractersticas, definitivamente no son competitivos comparando con Dreamhost. Adems, tener un ordenador siempre encendido en casa no es exactamente gratis: adems 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. Segn el servidor usado, es posible que tengamos poca velocidad de respuesta y las pginas dinmicas no se generen rpidamente. Poca capacidad de respuesta ante picos inesperados de trfico. 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 ms recomendable tener un dispositivo elctrico 247 encendido: Aunque no es lo ms probable, el cable se podra calentar, derretir, generar un cortocircuito y causar un incendio. Preocupacin 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? Cmo reaccionar rpidamente ante una avera hardware? Qu haces si se va la luz? Es necesario invertir tiempo en la administracin 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 ms provechoso es lo que se aprende de las tecnologas web. Con l podremos ver cmo configurar Apache, cmo reparar nuestras bases de datos MySQL, cmo mantener nuestro sistema estable para tener que hacer el mnimo nmero de paradas posible, cmo crearnos scripts para tener todos los aspectos de nuestro servidor monitorizados y controlados, cmo estudiar los logs, cmo administrar un servidor web de verdad que sirve pginas de verdad! En mi caso, adems, que uso WordPress, el hosting casero me ha permitido hacer lo que he querido con l. He modificado el cdigo como me ha parecido y he instalado los plugins que me han parecido tiles sin las restricciones de WordPress.com. Gracias a eso, tambin 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 pginas dinmicas y har volar al Apache pero: No es ese el ordenador que vas a usar para todo lo dems? Con ese pedazo de tarjeta de vdeo no vas a usarlo para algn juego 3D? Seguro que lo reiniciars lo justo? T te has dado cuenta del ruido que hacen sus ventiladores? Adems, el precio del kWh es de unos 0.09 cetimos de , as que a poco que consuma 300W, estamos hablando de 300x24x365x0.09/1000=236 al ao (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 podra servir, pero apostara sin dudarlo mucho a que tambin consume lo suyo y a que hace incluso ms ruido que el nuevo. Es una buena opcin, y si no te importa mucho el consumo elctrico, definitivamente podra ser lo que necesitamos. Sin embargo, recordemos que tu casa es ese sitio al que vas despus de un duro da y donde esperas encontrar paz, tranquilidad y el descanso del guerrero. Llegar y encontrarte ese odioso ordenador haciendo ruido un da y otro, y otro tambin y sin que te puedas permitir apagarlo, quizs no es lo que ms te apetezca. S, ya s que t tal vez ya tienes ese mismo ordenador muchos das encendido bajando cosas con aMule y con Bittorrent, pero de vez en cuando lo apagas, no? Ah! Cmo? Que noooooo? Bueno, a lo que quera llegar, es que a menos que tengis una casa de 200m2 con una habitacin por ah perdida donde encerrar el ordenador bajo llave para no orlo, seguramente necesitis otra cosa. Si lo que queremos es el servidor perfecto para un HC profesional, vlgame la contradiccin, lo que nos hace falta es un ordenador de bajo consumo y sin ventiladores. Hasta hace poco, los procesadores lderes indiscutibles en esta categora 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 propsito; los drivers para el procesador grfico no son lo mejor del mundo, pero no es algo realmente importante si slo 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 Espaa por EPATec) o la Elite C7VCM (con fuente de alimentacin DC-DC integrada), todas ellas ms baratas que las VIA EPIA, pero no creo que me equivoque mucho si digo que probablemente hay muchsima ms documentacin y experiencia sobre las VIA EPIA que sobre otros modelos (sin entrar en la terica superior calidad de unas sobre otras). Pero deca hasta hace poco porque Intel y AMD no estn 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 tambin en este segmento de mercado igual que ha hecho con AMD en los segmentos de procesadores para ordenadores de sobremesa y en procesadores para porttiles. Su nueva placa base D210GLY, con procesador de refrigeracin 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 lnea de flotacin 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 creacin de drivers de cdigo abierto, no dudara 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 ms rendimiento que uno de VIA. Josemanu de La Factora 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, slo cabra mencionar la memoria RAM y tal vez el disco duro, pero como cualquier tamao de disco duro superior a los 10GB ser ms que suficiente para casi cualquier propsito, quizs lo ms determinante pueda ser la RAM. En mi opinin, una cantidad razonable de RAM para manejar con soltura varias peticiones de Apache y el MySQL son 512MB, pero 256MB podran ser suficientes. Para finalizar la seccin, comentar que un porttil definitivamente no es una opcin como servidor. Pero ni como servidor de HC ni para tenerlo siempre encendido con programas P2P. Un porttil es un porttil. No estn preparados en absoluto para un estado de sobrecalentamiento permanente y a sus pequeos discos duros de 2.5 no les gusta que les tengan permanentemente dando vueltas y estarn 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 opinin no dan la talla para un servidor web completo como el que nos ocupa. Por cierto, Intel est a punto de revolucionar an ms 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 limitacin: el ancho de banda de subida. El acceso de banda ancha ms comn actualmente en Espaa 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 mximo nmero de usuarios que podremos atender simultneamente con una cierta fluidez. Esos 40KB/s tericos de subida pueden parecer poco, pero no son desdeables, ya que pueden suponer una transferencia mxima mensual terica de ms 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 comparacin 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 trfico procedente de los buscadores que tal vez s sea razonablemente uniforme, las visitas normalmente las tendremos a rachas: a ciertas horas del da, cuando se nos cita y enlaza desde otras pginas o cuando publicamos algo nuevo. Si

se nos amontonan las visitas, las pginas tardarn considerablemente ms en ser descargadas y la experiencia del usuario en nuestra pgina podra 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 slo existe la oferta de los 320kbps de subida. Ahora mismo tambin hay otras compaas de ADSL que ofrecen hasta 1Mbps de subida (con sus hasta 20Mbps de bajada). Sin embargo, cuando en algn momento me he planteado contratar alguna de esas alternativas, siempre me he encontrado docenas de mensajes en los foros de personas quejndose de cortes y microcortes frecuentes y reiterados que me han desanimado. Al final, la calidad de una de estas lneas con ADSL 2+ depender del ruido de la lnea y de la distancia del par de cobre hasta la central telefnica, pero en el mejor de los casos, su calidad parece claramente insuficiente si queremos dar un servicio de la forma ms 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 ms estables que los del ADSL 2+ y la aparicin del VDSL2 de la mano de Telefnica es inminente, al mismo tiempo que se acerca el FTTH. Otro aspecto que podemos plantarnos es la conveniencia de la IP fija. En Telefnica sale por 12 al mes, y nos podra facilitar enormemente muchos aspectos del HC. Sin embargo, slo por lo que cuesta, podramos contratar un hosting profesional, de modo que es una opcin que la mayora descartaramos. El dominio Por supuesto, vamos a necesitar uno o ms dominios para hacer realidad nuestro proyecto. Si tuviramos una IP fija, podramos comprar un dominio a cualquier registrador y hacer que el DNS apuntara a nuestra IP fija. En nuestro servidor tendramos que configurar un servidor de DNS adems de todos los otros servicios que quisiramos proporcionar. Sin embargo, con una IP dinmica tambin podremos montar nuestro HC sin problemas gracias a empresas como DynDNS o no-ip.com. En Piensas en si un da te roban el porttil? ya vimos una introduccin a cmo funcionan estos servicios y una gua de configuracin del ddclient en Debian para que actualice la IP tan pronto como sta cambie. Suponiendo dicha teora sabida, vamos a ver cmo ajustar la configuracin de DynDNS al entorno de un HC como el que estamos montando. DynDNS pone a nuestra disposicin un gran nmero 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 fcil encontrar una combinacin que sea de nuestro agrado. La ma, como los ms viejos del lugar saben, fue y es valencia.homelinux.org. Si queremos asociar una IP dinmica a un dominio propio, podemos considerar la opcin de comprar el servicio Custom DNS, que sale por 27.5$ al ao. Si tambin 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$/ao. 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 configuracin 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 podra ser un hostname diferente, en cuyo caso tendramos que aadir una lnea adicional en el ddclient.conf. La lnea:
use=web, web=checkip.dyndns.org/, web-skip='IP Address'

sirve para especificarle al ddclient dnde 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 pblica de Internet en uno de sus interfaces, algo cada vez ms raro hoy en da, podramos poner algo as:
use=if, if=eth0

El ddclient es capaz de conectarse a ciertos routers de diferentes formas para obtener la direccin directamente del router. Podemos consultar todas las posibilidades en la documentacin del ddclient. Para probar el correcto funcionamiento del ddclient, es una buena idea usar la opcin -v y la -force tambin puede ser necesaria para hacer troubleshooting ya que el cliente se niega a enviar una actualizacin 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 opcin es planificar el ddclient en el cron) y cada cunto tiempo debera de chequear si ha habido un cambio de IP (5 minutos por defecto, si lo ponemos ms 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 opcin, 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:

DynDNS 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 segn su README, por si preferimos uno alternativo a DynDNS:
Dynamic DNS services currently supported include: DynDNS.org Hammernode Zoneedit EasyDNS NameCheap See See See See See http://www.dyndns.org for details on obtaining a free account. http://www.hn.org for details on obtaining a free account. http://www.zoneedit.com for details. http://www.easydns.com for details. 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 versin 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 ms 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 pblico 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 distribucin de Linux bien mantenida, estable y con constantes actualizaciones de seguridad es perfectamente vlida para nuestro propsito. Y eso sin querer hacer un desprecio a las diferentes *BSD, que pueden ser una opcin tanto o ms buena que cualquier Linux, quizs destacando OpenBSD por su foco en la seguridad. Y Windows pues bueno, se podra tener un servidor de HC con Windows, pero las posibilidades de gestin y actualizacin remota se reduciran drsticamente. Definitivamente, no es la mejor opcin. El router En la mayora de los casos, nuestro servidor de HC estar detrs de un router que ser el que tenga la IP pblica del interfaz de WAN y que distribuir el trfico entre los equipos conectados a la LAN. Adems, no es que sea lo ms tpico, 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 opcin vlida. El router tenemos que configurarlo para que nuestro servidor de HC siempre reciba la misma direccin IP por DHCP, algo que la mayora de routers soportan asociando una direccin MAC determinada con una misma IP. Otra opcin es configurar el servidor para que use una IP fija y no la obtenga por DHCP, opcin ms 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. Adems, tendremos que abrir como mnimo 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 podrn usar el servidor de nombres de Internet para acceder a los servicios que proporciona el servidor (por ejemplo, para ver nuestra pgina 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 pequeo DNS que d servicio a la LAN, o introducimos en el fichero /etc/hosts de todos los sistemas (incluso en los Windows en c:\windows\system32\drivers\etc\hosts) 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 propsito. Nuestro servidor de HC debera estar conectado por cable al router. La conexin 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 destacara la de los vecinos. En mi casa, por ejemplo, yo detecto multitud de seales Wi-Fi diferentes de vecinos que me provocan graves interferencias y que ni siquiera me permiten recibir la seal del router en otra habitacin 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 seal del vecino causa interrupciones en la tuya. Definitivamente, no parece lo ms conveniente. El servidor web Hablar de servidor web en un sistema UNIX es casi sinnimo 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 mo, pero en general, tiene muy buena prensa, especialmente en lo que toca a consumo de memoria. En la grfica de Febrero de Netcraft, vemos que lighttpd ya va hacindose ver con su milln 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 configuracin. 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 cdigo y su mayor novedad fue que funcionaba con threads UNIX. Aunque su rendimiento es mejor en general, su adopcin ha sido muy lenta porque muchos de los mdulos existentes para Apache 1.3 no existan en Apache 2.x y porque la documentacin de PHP desaconsejaba usarlo. En la actualidad, las instrucciones de instalacin 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 segn la documentacin de PHP (Apache MPM prefork). Si miramos su descripccin, vemos que permite usar Apache 2 de una forma similar a la que funcionaba Apache 1.3 evitando problemas con libreras 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 mdulo 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 slo comando un sistema LAMP (Linux+Apache+MySQL+PHP) en Debian, slo 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 ms viejas. Los hostings profesionales ya son bastante rcanos en cuanto al uso de versiones modernas (hace poco me encontr con uno que an usaba MySQL 3!), como para que nosotros les emulemos. Si la versin es estable para Debian,

tambin lo es para m. Por tanto, una vez que tenemos el Apache 2.2 instalado, en Debian tenemos un fichero de configuracin global en /etc/apache2/apache2.conf. Desde ese fichero se incluye el /etc/apache2/httpd.conf, que por defecto est vaco y preparado para que nosotros introduzcamos nuestras lneas de configuracin 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 mdulos 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 mdulos y sitios virtuales que queremos habilitar. En las entradas de compresin y cacheo de Apache vimos cmo habilitar y configurar los mdulos: 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 ms informacin sobre los aspectos particulares de configuracin de Apache en Debian en el fichero /usr/share/doc/apache2.2-common/README.Debian.
Configuracin de los sitios virtuales

Por defecto, Debian slo 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 configuracin de sitio virtual especfica. Tiene el directorio base de documentos en /var/www/apache2-default/ y nos permite recorrer la documentacin del servidor slo 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 configuracin bsica 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 configuracin con ficheros .htaccess, tendremos que quitar las lneas AllowOverride None. Si queremos presentar un documento personalizado para errores 404, podemos incluir una lnea 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 imgenes de nuestro sitio desde otro sitio) es especialmente daino, por lo que deberamos de prevenir hasta donde sea posible el robo de imgenes. Una buena forma de hacerlo es rechazando las peticiones cuyo referer no sea nuestra propia pgina o ninguno (hay firewalls que los eliminan, la extensin No-Referer de Firefox tambin los elimina, e incluso podemos controlarlo en Firefox con el parmetro 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>

Adems, en mi caso, cuando cambi el dominio principal de valencia.homelinux.org a www.vicente-navarro.com, tuve que implementar una redireccin 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 estn acabadas.
Poniendo en marcha la nueva configuracin

Cuando hagamos cualquier cambio a los ficheros de configuracin de Apache y queramos que tengan efecto interrumpiendo de forma mnima el servicio, tenemos que tener la precaucin de chequear que estn 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

Adems, el apache2ctl restart mata las conexiones que estuvieran activas en ese momento. Es por eso que es mucho ms 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 configuracin 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 ningn problema de configuracin o que estemos sufriendo algn 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 muchsimas 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 estn sirviendo. Es por ello que yo descubr que bajando el nmero mximo de clientes que se pueden atender (MaxClients) en el apache2.conf de los 150 de por defecto a 50, en casos de avalancha, la mquina no se agobiaba y a aquellos clientes que aceptaba, les serva ms o menos correctamente. Haba muchos que no eran aceptados, eso s, pero que en cualquier caso, por el ancho de banda no se les poda 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 ms informacin sobre cmo configurar Apache en la pgina de documentacin de Apache 2.2.
Moderacin con el tamao de lo que publicamos

Y es precisamente por la limitacin 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 pgina de nuestro sitio puede suponer una verdadera bofetada a nuestros visitantes que tendrn que esperar segundos y segundos a que la pgina acabe de cargar y eso si finalmente esperan y no la cierran antes. Por eso, cuidado con lo que hospedamos y seamos muy tacaos con el escaso ancho de banda con el que contamos. Antes haca referencia a entradas previas que trataban de la compresin y cacheo de las pginas web. Con dicha tcnica podremos reducir al mnimo el volumen de los ficheros HTML, CSS y JavaScript, pero el objetivo de mantener a un tamao razonable las imgenes 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 peridicamente toda nuestra web. Una solucin 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 pginas de categoras, las de etiquetas, los archivos al fin y al cabo, es slo contenido duplicado que lo nico que puede hacer es confundir al buscador a la hora de decidirse por la mejor pgina. Pero la jugada maestra para ahorrar ancho de banda es prohibir a los buscadores que indexen las imgenes de nuestro sitio (Remove an image from Google Image Search). La gente que busca imgenes, raramente estar interesada por el contenido de nuestra pgina en s mismo. Por ello, prohibiendo la bsqueda de imgenes, evitamos por un lado el gasto de ancho de banda de servir nuestras imgenes a los buscadores de imgenes y por otro, el de aquellos que acceden a nuestra pgina buscando imgenes, 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 trfico proveniente de buscadores de imgenes. En mi caso, el nmero de visitas procedente de images.google.com lleg a ser muy alto hasta que prohib la bsqueda de imgenes en mi sitio, ya que analizando las bsquedas origen de las visitas, llegue a la conclusin de que no eran visitantes interesados en el contenido de mis pginas. 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 travs 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 compresin o para estudiar las consecuencias que los cambios en el cdigo pueden suponer (por ejemplo, tras introducir un trozo de cdigo PHP muy complejo de ejecutar y que tal vez resulte muy lento). En esta prueba de ejemplo, le lanzo a mi servidor a travs de la LAN peticiones de 5 en 5 (-c 5) durante un tiempo mximo de 60 segundos (-t 30), y veo que es capaz de atender 23 peticiones (los fallos Length: 21 son porque las pginas devueltas no tienen todas el mismo tamao, algo que no es un problema en este caso), pero que algunas han tenido que esperar hasta 40 segundos:
# ab -c 5 -t 60 http://www.vicente-navarro.com/blog/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/ Benchmarking www.vicente-navarro.com (be patient) Finished 23 requests

Server Software: Server Hostname: Server Port: Document Path: Document Length: Concurrency Level: Time taken for tests: Complete requests: Failed requests: (Connect: 0, Length: Write errors: Total transferred: HTML transferred: Requests per second: Time per request: Time per request: Transfer rate:

Apache/2.2.3 www.vicente-navarro.com 80 /blog/ 63231 bytes 5 60.523663 seconds 23 21 21, Exceptions: 0) 0 1510651 bytes 1505035 bytes 0.38 [#/sec] (mean) 13157.318 [ms] (mean) 2631.464 [ms] (mean, across all concurrent requests) 24.37 [Kbytes/sec] received

Connection Times (ms) min mean[+/-sd] median Connect: 0 0 0.0 0 Processing: 2319 11847 9921.7 9117 Waiting: 1251 5547 7283.9 2763 Total: 2319 11847 9921.7 9117

max 0 40440 30366 40440

Percentage of the requests served within a certain time (ms) 50% 8977 66% 14074 75% 15522 80% 18804 90% 27300 95% 29838 98% 40440 99% 40440 100% 40440 (longest request)

Volvamos a repetir la prueba tras habilitar el plugin para WordPress WP Super Cache, del que ya hablamos en Comprimir y cachear las pginas generadas por WordPress y veremos que de las decepcionantes 23 peticiones servidas pasamos a nada menos que 8193 peticiones con un tiempo de espera mximos de 71ms:
# ab -c 5 -t 60 http://www.vicente-navarro.com/blog/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/ Benchmarking www.vicente-navarro.com (be patient) Completed 5000 requests Finished 8193 requests

Server Software: Server Hostname: Server Port: Document Path: Document Length: Concurrency Level: Time taken for tests: Complete requests: Failed requests: Write errors: Total transferred: HTML transferred: Requests per second: Time per request: Time per request: Transfer rate:

Apache/2.2.3 www.vicente-navarro.com 80 /blog/ 63301 bytes 5 60.358 seconds 8193 0 0 520941496 bytes 518752897 bytes 136.55 [#/sec] (mean) 36.617 [ms] (mean) 7.323 [ms] (mean, across all concurrent requests) 8478.80 [Kbytes/sec] received

Connection Times (ms) min mean[+/-sd] median Connect: 0 3 2.5 3 Processing: 13 32 4.1 33 Waiting: 2 8 4.4 8 Total: 18 36 4.1 36

max 26 69 49 71

Percentage of the requests served within a certain time (ms) 50% 36 66% 37 75% 38 80% 39 90% 41 95% 43 98% 45 99% 46 100% 71 (longest request)

Ah! Y si permitimos la compresin con la opcin -H "Accept-Encoding: gzip", el resultado es incluso ms espectacular, llegndose a las 16122 peticiones servidas, aunque ahora la diferencia ya era previsible, ya que es debida slo a que ahora se sirven menos datos:
# ab -c 5 -t 60 -H "Accept-Encoding: gzip" http://www.vicente-navarro.com/blog/ [...] Complete requests: 16122 [...]

Por supuesto, lo ideal es hacer estas pruebas desde otro sistema de Internet, donde el cuello de botella del ancho de banda se note, pero estas pruebas desde la LAN tambin pueden ser muy ilustrativas y tiles para entender por dnde cojea nuestre servidor web. El servidor de correo Los dos servicios bsicos de un hosting son el servidor web y el servidor de correo, as que de nuestro HC tambin podramos esperar que fuera un buen servidor de correo. Sin embargo, quitando la parte de que un servidor de correo como sendmail o exim puede ser realmente difcil de configurar, la realidad es que en la actualidad, siendo el spam un problema tan grande en Internet, un servidor de SMTP funcionando desde una red de usuarios finales con IPs dinmicas es candidato seguro a ser ignorado por casi todos los servidores de correo de Internet. E incluso aunque nuestra IP fuera fija, al no ser la IP conocida de un ISP profesional, lo ms probable es que nuestros correos tambin fueran rechazados por un alto porcentaje de servidores destino. Adems, no podremos cambiar la resolucin inversa de la IP, algo que muchos servidores de correo verifican. Por ejemplo, imaginemos que instalo el paquete exim4, y lo configuro con dpkg-reconfigure exim4-config como servidor SMTP del dominio hostingcasero.homelinux.org (para direcciones como usuario@hostingcasero.homelinux.org). Elegimos que el General type of mail configuration sea internet site:

En System mail name ponemos hostingcasero.homelinux.org:

En IP-addresses to listen on for incoming SMTP connections lo podemos dejar vaco para que el servidor acepte conexiones SMTP por todos los interfaces de red:

En Other destinations for which mail is accepted, pondremos el hostname de nuestro servidor, as como hostingcasero.homelinux.org:

El Domains to relay mail for en principio lo podemos dejar vaco, as como el Machines to relay mail for. El Keep number of DNS-queries minimal (Dial-on-Demand)? no tiene mayor importancia en nuestra configuracin, as como el Delivery method for local mail y el Split configuration into small files?, que ya van segn las preferencias de cada uno. Pues bien, a finalizar me encuentro con que si intento enviar un e-mail a Hotmail me dice que no acepta mi correo porque mi IP no es de fiar:

# mail nospam@hotmail.com < /tmp/correo.txt delivering 1JY4zH-0001ym-VM R: dnslookup for nospam@hotmail.com T: remote_smtp for nospam@hotmail.com Connecting to mx2.hotmail.com [65.54.244.168]:25 ... connected SMTP<< 220 bay0-mc2-f2.bay0.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft's computer network is prohibited. Other restrictions are found at http://privacy.msn.com/Anti-spam/. Violations will res SMTP>> EHLO localhost SMTP<< 250-bay0-mc2-f2.bay0.hotmail.com (3.5.0.22) Hello [81.39.245.151] 250-SIZE 29696000 250-PIPELINING 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-AUTH LOGIN 250-AUTH=LOGIN 250 OK SMTP>> MAIL FROM:<root@hostingcasero.homelinux.org> SIZE=1367 SMTP>> RCPT TO:<nospam@hotmail.com> SMTP>> DATA SMTP<< 550 DY-001 Mail rejected by Windows Live Hotmail for policy reasons. We generally do not accept email from dynamic IP's as they are not typically used to deliver unauthenticated SMTP e-mail to an Internet mail se SMTP>> QUIT LOG: MAIN ** nospam@hotmail.com R=dnslookup T=remote_smtp: SMTP error from remote mail server after MAIL FROM:<root@hostingcasero.homelinux.org> SIZE=1367: host mx2.hotmail.com [65.54.244.168]: 550 DY-001 Mail rejected by Windows LOG: MAIN <= <> R=1JY4zH-0001ym-VM U=Debian-exim P=local S=1777 LOG: MAIN Completed

Pero en cambio, GMail s que me lo acepta:

# mail nospam@gmail.com < /tmp/correo.txt delivering 1JY51y-0001yu-LW R: dnslookup for nospam@gmail.com T: remote_smtp for nospam@gmail.com Connecting to gmail-smtp-in.l.google.com [216.239.59.27]:25 ... connected SMTP<< 220 mx.google.com ESMTP g11si5603645gve.6 SMTP>> EHLO localhost SMTP<< 250-mx.google.com at your service, [81.39.245.151] 250-SIZE 28311552 250-8BITMIME 250 ENHANCEDSTATUSCODES SMTP>> MAIL FROM:<root@hostingcasero.homelinux.org> SIZE=1363 SMTP<< 250 2.1.0 OK SMTP>> RCPT TO:<nospam@gmail.com> SMTP<< 250 2.1.5 OK SMTP>> DATA SMTP<< 354 Go ahead SMTP>> writing message and terminating "." SMTP<< 250 2.0.0 OK 1205005717 g11si5603645gve.6 SMTP>> QUIT LOG: MAIN => nospam@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [216.239.59.27] LOG: MAIN Completed

aunque segn mi experiencia, dependiendo de la IP dinmica que te haya tocado, es muy posible que tambin se te rechacen los correos si alguna vez la ha tenido alguien sospechoso de mandar spam. En definitiva, es un servicio nada fiable. Si tenemos un dominio propio con Custom DNS, crear un registro SPF en el DNS puede ayudar para que no rechacen los correos de tu servidor. En openspf.org tienen un formulario que nos ayuda a confeccionar uno adecuado para nuestro servidor. Las MSN Hotmail Guidelines son un buen sitio donde contrastar todos estos requisitos, que suelen ser bastante comunes: 1. Sender is expected to comply with all technical standards for the transmission of Internet e-mail, as published by The Internet Societys Internet Engineering Task Force (IETF), including RFC 2821, RFC 2822, and others. 2. After given a numeric SMTP error response code between 500 and 599 (also known as a permanent non-delivery response), the sender must not attempt to retransmit that message to that recipient. 3. After multiple non-delivery responses (see #2), the sender must cease further attempts to send e-mail to that recipient. 4. Sender must not open more than 500 simultaneous connections to MSN Services inbound e-mail servers without making prior arrangements. 5. Messages must not be transmitted through insecure e-mail relay or proxy servers. 6. The mechanism for unsubscribing, either from individual lists or all lists hosted by the sender, must be clearly documented and easy for recipients to find and use. 7. Connections from dynamic IP space may not be accepted. 8. E-mail servers must have valid reverse DNS records. Y fijmonos adems en lo que nos deca el mensaje de rechazo de Hotmail: Mail rejected by Windows Live Hotmail for policy reasons. We generally do not accept email from dynamic IPs as they are not typically used to deliver unauthenticated SMTP e-mail to an Internet mail server. http://www.spamhaus.org maintains lists of dynamic and residential IP addresses. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support. Esa lista que menciona de Spamhaus no slo la usa Microsoft, sino que muchas otras empresas e ISPs se basan en ella para descartar los correos desde determinados rangos de IPs en funcin de la lista. Con los correos entrantes no tendremos ningn problema siempre que nuestro servidor est arriba. Los servidores SMTP que nos quieran mandar correo buscarn el registro MX (o el A si no hay MX) en elDNS y salga la IP que salga, ah se mandar el correo. Para recuperar los correos recibidos en el servidor, puede ser suficiente el clsico comando mail, o con un simple apt-get install qpopper, podemos tener un servidor de POP3 listo en pocos segundos. Sin embargo, si nuestro servidor no est arriba por algn problema cuando otro servidor SMTP quiera conectarse al nuestro para enviarle un e-mail, el servidor remoto tendr que decidir si reintenta el envo ms tarde o si lo descarta, por lo que el servicio de recepcin de correos tampoco es fiable. Si realmente queremos tener un servidor de correo fiable en nuestro sistema, la solucin definitiva puede venir por contratar el servicio de DynDNS MailHop Relay (42.5$/ao), especficamente pensado para estos problemas. El servidor SMTP de DynDNS es el que da la cara y nosotros lo usamos como smarthost para mandar los correos a travs de l y viceversa, para que l nos los enve de vuelta, guardndolos temporalmente si nuestro servidor est cado. Bytecoders tambin trat estos temas hace poco en Aviso de actualizaciones en Debian por e-mail y SMTP: la lacra del SPAM.
Correo con nuestro propio dominio con Google Apps

Para m, todos estos problemas con el correo se acabaron cuando apareci el Google Apps y pude usar el equivalente a GMail (con su POP3 y su IMAP) pero creando diferentes direcciones sobre mi propio dominio (vicentenavarro.com). Para ello, lo nico que tuve fue darme de alta en el servicio y apuntar los registros MX de mi dominio a los servidores de Google (Configuring Your MX Records):
# nslookup > set querytype=MX > vicente-navarro.com Server: 80.58.61.250 Address: 80.58.61.250#53 Non-authoritative answer: vicente-navarro.com mail exchanger = 10 alt1.aspmx.l.google.com. vicente-navarro.com mail exchanger = 15 alt2.aspmx.l.google.com. vicente-navarro.com mail exchanger = 5 aspmx.l.google.com. Authoritative answers can be found from: alt1.aspmx.l.google.com internet address alt1.aspmx.l.google.com internet address alt2.aspmx.l.google.com internet address aspmx.l.google.com internet address

= = = =

72.14.215.114 72.14.215.27 64.233.179.27 216.239.59.27

Tras esto, cre buzones de correo (o alias) para cada una de las cuentas que iba a usar y reconfigur mi servidor para que usara un smarthost:

Y para que usara smtp.google.com como smarthost:

el resto de la configuracin, puede quedar igual que estaba antes. Bueno, igual pero no se nos tiene que olvidar poner nuestro dominio en el apartado de System mail name. Lo nico que tendremos que tener en cuenta es que ahora los correos no se reciben localmente sino en la cuenta de Google Apps (lo que en realidad es ms cmodo), pero si an as fuera necesario traer esos correos a nuestro servidor, siempre podramos configurarlo para que se los trajera de Google usando POP3. Por supuesto, Google requiere autentificacin para mandar correos a travs de l, por lo que en el fichero /etc/exim4/passwd.client tendremos que asociar nuestro usuario y contrasea de Google Apps al servidor SMTP:
# password file used when the local exim is authenticating to a remote # host as a client. # # see exim4_passwd_client(5) for more documentation # # Example: ### target.mail.server.example:login:password gmail-smtp.l.google.com:cuentaadministrador@vicente-navarro.com:contrasenya

Independientemente de que vayamos a usar el servidor de HC para enviar y recibir correos en serio o no, es indudable que necesitamos tenerlo bien configurado como servidor de correo para que podamos mandarnos advertencias sobre problemas que pueda haber en el servidor desde nuestros scripts de monitorizacin. O, simplemente, porque aplicaciones como WordPress mandan correos cada vez que llega un nuevo comentario, por ejemplo. Si el servidor

de correo no est bien configurado, las aplicaciones que envan correos como parte de su funcionamiento normal, no podrn hacerlo. Otras cuestiones
Backups #!/bin/bash while ! queda_claro do insistir_en_el_backup done no_se_puede_insistir_bastante

Creo que no hace falta decir ms. Tenemos todo el trabajo invertido en configurar nuestro servidor casero, las bases de datos con los comentarios de nuestros visitantes, nuestras imgenes, nuestro trabajo ah. De verdad nos vamos a arriesgar a que el disco duro falle o a que inadvertidamente hagamos un rm -rf * y desaparezca todo de un plumazo? Para esta tarea, rysnc es nuestro mejor amigo (Backups con rsync), aunque herramientas como tar o cpio tambin pueden ayudar. Yo recomendara una copia de todos los ficheros importantes en algn directorio del propio servidor casero y otra/s copia/s en otro/s sistema/s que tengamos a travs de de la red con rsync. Para exportar todas las bases de datos MySQL del sistema e incluirlas en el backup, podemos hacer un:
mysqldump -uroot -ppassword --all-databases > backup_mysql.bak

y lo podramos recuperar con un:

mysql -uroot -ppassword < backup_mysql.bak

Ms detalles sobre cmo usar el mysqldump en mysqldump A Database Backup Program.

El sistema de respaldo

Durante el ao habr algunos das, semanas o meses que pases fuera de tu casa. Seguramente esos das te querrs dejar la luz, el agua y el gas de casa cerrados para prevenir incidentes. Qu haces con el servidor casero? Tiene que seguir dando servicio! Si tienes la suerte, como yo, de contar con algn otro ordenador que pueda servir tambin de servidor casero y de tener algn familiar/amigo con conexin a Internet y que consienta en tenerlo en su casa, una especie de housing casero, lo tenemos muy fcil: Instalamos la misma versin de sistema operativo que en el servidor oficial y lo llevamos a su nuevo destino. Creamos un nuevo nombre para el otro sistema en DynDNS y lo configuramos para que el ddclient del nuevo sistema lo actualice, pero muchsimo mejor si podemos configurar el router de la otra casa para que lo haga automticamente. Opcional: Preparamos el router y el sistema hospedado en casa ajena para arrancar con Wake on Lan. Tenemos que tener en cuenta que si no es el router el que se encarga de actualizar la IP en DynDNS, podemos tener el problema de no saber la IP de destino para enviarle el paquete mgico. Le ponemos una IP fija al sistema o configuramos el router para que le asigne por DHCP siempre la misma y abrimos los puertos necesarios en el router. Creamos una batera de scripts basados en rsync y SSH para sincronizar todos los ficheros de configuracin necesarios y adaptar los que varan en el nuevo sistema (por ejemplo, el /etc/ddclient.conf). Tambin deberan actualizar las bases de datos y reiniciar los procesos necesarios tras modificar la configuracin. Tener previstos otros scrips para pasar el servicio de un sistema a otro. Al final, esto slo consiste en que el sistema que sea el primario actualice los registros DNS con su IP y el secundario deje de hacerlo. Tras la estancia en el otro sistema, tendremos que sincronizar los cambios de vuelta al sistema principal y probablemente querramos recoger los logs que se hayan generado all. Este sistema de respaldo no slo nos puede servir en caso de tener que apagar nuestro servidor habitual. Tambin lo podemos utilizar mientras hacemos tareas de mantenimiento o si en tenemos problemas con la conexin a Internet o estamos sufriendo un apagn.
Los cortes de corriente

Otro de los problemas con los que nos tendremos que enfrentar sern los cortes de corriente. Aunque no son muy frecuentes, de vez en cuando tendremos uno y tenemos que tener previsto qu hacer cuando ocurran. Si se trata de un breve corte, lo ms importante es que el servidor arranque slo cuando vuelva a recibir corriente. Para ello, tenemos que buscar el parmetro de nuestra BIOS que lo permite. Por ejemplo, en una VIA EPIA SP8000E, el parmetro se llama AC Loss Auto restart y podemos hacer que la mquina se encienda siempre cuando vuelva la luz, que no se encienda nunca o que vuelva al estado anterior: AC Loss Auto restart The field defines how the system will respond after an AC loss during system operation. Off: Keeps the system in an off state until the power button is pressed On: Restarts the system when the power is back Former-Sts: Restores the system to its previous state

En una placa Asus A8N-SLI, el parmetro se llama Restore on AC Power Loss y slo tiene dos valores posibles, activado o desactivado:

Pero si queremos estar prevenidos de verdad ante cortes de corriente, la mejor opcin es tener un SAI al que conectar el servidor y el router que da acceso a Internet. Si el servidor es un sistema de bajo consumo, tendremos bastante tiempo de margen para esperar a que vuelva la luz, o al menos, el tiempo suficiente para actualizar nuestro servidor de respaldo por si tiene que entrar en accin.
Mantenimiento remoto

La posibilidad de conectarnos por SSH a nuestro servidor casero siempre tiene que estar abierta. En mi experiencia, un servidor SSH abierto en Internet trae infinidad de intentos de conexin con reiteradas pruebas con distintos usuarios. Sin ir ms lejos, hoy mismo, alguien ha probado 1520 combinaciones diferentes de usuario/contrasea en mi sistema
# grep "Invalid user" auth.log.0 | grep "Mar 1520 9" | wc -l

Algunos ejemplos:
Mar Mar Mar Mar Mar 9 9 9 9 9 06:15:05 06:15:09 06:40:08 06:40:11 06:40:15 telemaco telemaco telemaco telemaco telemaco sshd[6028]: sshd[6032]: sshd[7742]: sshd[7746]: sshd[7750]: Invalid Invalid Invalid Invalid Invalid user user user user user ibm from 61.250.91.34 informix from 61.250.91.34 stevie from 61.250.91.34 kelly from 61.250.91.34 rasoul from 61.250.91.34

Es por eso que lo mejor es deshabilitar completamente el acceso con usuario/contrasea y permitir exclusivamente la autentificacin por clave pblica/privada: Autentificacin trasparente por clave pblica/privada con OpenSSH. Cambiar el puerto del servidor SSH (por defecto 22) a otro tambin puede ser una medida til para evitar algunos de estos insistentes intentos de acceso. Otra herramienta de mucha utilidad para el mantenimiento remoto es conectar un mdem a nuestro servidor casero, tal y como vimos en: Configurar Linux para permitir el acceso remoto por mdem a la consola y por RAS/PPP. En casos en que el router haya perdido la conexin a Internet, podemos tratar de conectarnos por mdem y a travs del interfaz de configuracin por telnet del router tratar de reiniciarlo. Otra situacin til es en caso de una avalancha de peticiones en la que t mismo no puedes acceder por el router por la absoluta falta de ancho de banda y, en ese caso, la entrada por la puerta de atrs nos puede servir para llegar al sistema sin usar Internet.
P2P y hosting casero?

Supongamos que necesitamos bajarnos el ltimo DVD de Knoppix por Bittorrent. Es compatible el P2P con sus altas necesidades de ancho de banda con el HC? Pues en principio, puede serlo -en funcin del nmero de visitas que recibamos- siempre que limitemos el ancho de banda de subida disponible para P2P a un lmite que permita servir los contenidos hospedados a una velocidad razonable. En el mejor de los casos, el uso de P2P en la misma conexin de un HC ir completamente en detrimento de la experiencia de nuestros visitantes, aunque slo tengamos uno en ese momento, pero que notar que la pgina descarga ms lenta. El mejor consejo al respecto es que si activamos el P2P, deberamos de estar pendientes de que el tiempo de respuesta sea un mnimo aceptable probando nosotros mismos a conectarnos desde otro sistema de Internet. Si vemos que va muy lento, deberamos desactivar el P2P. Por supuesto, en caso de un pico de visitas, deberamos de desactivar el P2P inmediatamente.
Scripting

Cualquier administrador que se encargue de un servidor UNIX tiene que estar continuamente crendose scripts para no realizar las mismas tareas una y otra vez. Para nosotros, como administradores de nuestro HC no va a ser distinto. Deberamos de tener unos conocimientos mnimos de scripting que nos sern muy tiles para hacer backups, para analizar logs, para monitorizar el estado de algn proceso, para enviar e-mails con advertencias, etc. A lo largo de este ao, yo me he llegado a crear un buen nmero de scripts. La mayora son muy especficos de mis necesidades particulares, pero me gustara dejar aqu uno muy sencillito que nos manda un e-mail cada vez que el ISP nos cambia la direccin IP dinmica:
#!/bin/bash cd /root/scripts_ip mv -f ippublica ippublica.old ./ippublica.sh > ippublica if ! diff ippublica ippublica.old > /dev/null then cat cabecera ippublica | mail -s "La IP del servidor ha cambiado - `date +\"%g/%m/%d %H:%M\"`" user@example.com fi

El ippublica.sh puede ser, bien una peticin por SNMP al router para ver cul es la IP del interfaz de WAN:
snmpwalk -c comunidad -v 1 192.168.1.1 IP-MIB::ipAdEntAddr|egrep -v '0\.0|192\.168' | awk '{print $4}'

bien un acceso a checkip.dyndns.org:

/usr/bin/wget -q -O - http://checkip.dyndns.org/index.html | /usr/bin/fromdos | /bin/sed 's_<html><head><title>Current IP Check</title></head><body>Current IP Address: __' | /bin/sed 's_</body></html>__'

El fichero cabecera es algo como:

La IP del servidor es ahora:

Conclusin En esta entrada he tratado de recopilar lo ms importante de lo que me ha sido necesario conocer durante un ao completo de autohospedaje en el que creo que el resultado ha sido bastante satisfactorio. Por carambolas del destino, ahora ya he pasado a un hosting profesional, pero la travesa ha valido la pena y la repetira tantas veces como hiciera falta. Si alguien tiene intencin de adentrarse en esta aventura ha de saber que aprender mucho y espero que en estas lneas encuentre consejos que le sean de utilidad, como creo que me hubieran sido a m. Tambin hay que tener en cuenta que tambin es posible tener un hosting casero sin tomrnoslo muy en serio, de forma que no nos importe en absoluto si tenemos la pgina cada varios das seguidos, pero creo que si nos ponemos, vale la pena hacerlo lo mejor posible. No hay nada que d peor impresin en Internet que una pgina que tarda en cargar o que cada dos por tres est cada. Esa no es la forma de fidelizar a nuestros lectores. El HC es un poco como tener un perro en casa. Puede ser divertido, te dar muchas satisfacciones, pero a cambio ganas muchas obligaciones: Tienes que estar pendiente de l, te da trabajo y no puedes irte de vacaciones sin buscarle un acomodo. :wq Entradas relacionadas Piensas en si un da te roban el porttil? (6) Servir con Apache imgenes con marca de agua (watermark) (5) Primer aniversario del blog (5) Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (5) Probando el mod_deflate de Apache (4) mailto: sin miedo a spammers (4) Esta entrada fue publicada bajo una licencia CC el 9 marzo 2008 a las 17:32 y pertenece a la categora GNU/Linux, Internet, LAMP/WordPress, Redes, Sobre el Blog. Etiquetas: Apache, backup, blog, ddclient, Debian, DNS, DynDNS, exim, GNU/Linux, Google, hosting, Internet, modem, MySQL, OpenSSH, PHP, rsync, shell, SMTP, spam, VIA EPIA, wget, WordPress, Zyxel 660HW. Puedes seguir las respuestas a travs de RSS. Ya no se pueden dejar comentarios, pero puedes hacer trackback desde tu pgina.