Máquinas Virtuales

Una máquina virtual (VM por Virtual Machine) es un entorno de software que recrea las características de un equipo real de modo que podamos -para decirlo en términos simples- tener una computadora dentro de otra. Una máquina virtual tiene su propio Bios, hardware y sistema operativo con independencia de lo que utilice la máquina real que la aloja.

Las aplicaciones son variadas, desde emular entornos de hardware no disponibles por antiguedad, precio, etc. hasta consolidar múltiples equipos en uno sólo con fines de ahorro o simplificación de administración.

Hemos experimentado con máquinas virtuales desde hace varios años, pero siempre sólo para probar aplicaciones desarrolladas en VIS bajo diferentes entornos. También para probar algunas aplicaciones externas o software de dudosa procedencia sin comprometer las máquinas reales.

Recientemente, nos hemos aventurado a utilizarlo con un fin más interesante: nuestros servidores de hosting compartido. Las ventajas son enormes, especialmente por la forma en que VIS organiza sus servicios.

Concentrar todos los servicios en un único servidor es una pésima idea.

Separar todos los servicios en equipos independientes es muy costoso.

Una buena opción es agrupar los servicios en dos o tres equipos.

Una opción mucho mejor es separar todo en máquinas virtuales y distribuirlas en los mismos dos o tres equipos reales. ¿Por qué?

Las ventajas son muchas:

• La administración puede ser más refinada y precisa: se puede afinar al detalle los servicios o mantenerlos separados y controlados de manera que no interfieran entre ellos.
• Se puede ajustar los recursos asignados a cada servicio según la demanda lo requiera. Incluso se puede independizar un servicio en un equipo real independiente si el consumo así lo requiere.
• Se puede "clonar" equipos muy fácilmente, con toda la configuración ya lista.
• El costo no se eleva significativamente pero sí se requiere mayores conocimientos para poder administrar el conjunto.
• Migrar a equipos más potentes se reduce a mover la máquina virtual de un equipo a otro.

Existen muchas plataformas de virtualización en constante desarrollo, algunas comerciales, otras de código abierto: VMware, Hyper-V, KVM, VirtualBox, Xen, etc.

Como siempre, es cuestión de darse el tiempo -nunca suficiente- para experimentar con ellas y ver la forma de sacarles provecho.

Hosting compartido: ¿Todos los huevos en una sola canasta?

El hosting tradicional consiste en tomar UN servidor, instalarle un panel de control (cpanel en el 99% de los casos), agregarle todos los servicios necesarios (correos, webmail, sitios web, bases de datos, listas, filtros anti-spam, etc.) y repartir el acceso entre una determinada cantidad de clientes.

Suele suceder que -por ahorro de costos- se agregan demasiados clientes a un único servidor y entonces los problemas de rendimiento se agravan.

Imaginen a una sola persona que debe atender el teléfono, tomar notas de una reunión, escribir una carta, calcular los impuestos a pagar, atender a un cliente presencialmente, etc. todo al mismo tiempo. Basta que alguna de esas actividades le demande demasiada atención para que inevitablemente descuide las otras.

Es lo que sucede si al mismo servidor se le instalan cosas tan diferentes como una base de datos, un servidor de correo y un servidor web. Basta que a un usuario se le ocurra abrir un buzón muy grande o que el filtro anti-spam deba analizar un mail con attachments muy pesados o que un sitio web deba realizar una tarea pesada, para que el resto de servicios se vean afectados.

En una situación ideal, tendríamos varios servidores, uno por cada tarea de modo que puedan estar especialmente configurados para realizarla de la mejor manera. Siendo más servidores, pueden manejar una mayor cantidad de usuarios, lo que en cierta forma compensa el costo adicional, pero no evita que el conjunto sea más complicado de manejar. El principal problema es que las herramientas comúnmente utilizadas para administración (por ejemplo: cpanel) no están concebidas para este tipo de operación, por lo que simplemente los proveedores optan por el único camino que tienen (todo en el mismo server).

Como los extremos nunca son buenos, una solución intermedia aceptable es utilizar al menos dos servidores: uno para correo y otro para web. El servidor de correo puede concentrarse en los servicios SMTP, POP3, IMAP y quizá su propio webmail. El otro puede concentrarse en el sitio web (apache, php y mysql).

Otras tareas que demandan un elevado consumo de recursos de procesamiento pueden ser delegadas a servidores especializados. El mejor ejemplo es el filtrado anti-spam.

VIS emplea un esquema similar al mencionado, empleando no uno sino dos servidores de filtrado para todos sus servidores de correo. Funciona muy bien y permite realizar una serie de complejos procesos sin mayor impacto en el nivel de servicio, aunque muchas veces resulta complicado explicarle a un potencial nuevo cliente por qué un servicio cuesta significativamente más que el otro.

Conclusión: es mejor usar varios servidores especializados en determinadas tareas. Concentrar todos los servicios en un único equipo es una bomba de tiempo.

Made in Perú

He pasado las últimas 3 horas leyendo diversos webs, blogs, etc. sobre desarrollo de software en Perú. Con tanto trabajo algunas veces olvidamos darnos un baño de información nueva. ¿Mi conclusión? Mucho floro, palabreo y sigla bonita, pero muy poco desarrollo realmente peruano.

Drupal, Joomla, etc. ganan terreno. Veo con pánico cómo la historia de los ochentas a noventas parece repetirse: luego de un inicio humilde pero auspicioso, caemos en el facilismo de simplemente usar lo que otros producen en el extranjero.

Sólo basta navegar por los sitios web de los principales medios, tal parece que crear aplicaciones web se está convirtiendo en cuestión de crear skins, adecuar estilos y algunos plugins?

En los ochentas, cuando reinaban las computadoras de 8 bits, hubo algunos pocos que le encontraron el gusto a la programación. De esos pocos, un número aún menor se organizó en pequeños grupos que intentaban crear pequeñas producciones netamente peruanas. Era usual comprar revistas españolas de muy buena calidad sobre computación, donde además de aprender, se podía mirar de lejos la gran actividad del joven mundo informático en Europa.

Yo tenía 14 años cuando quedé sorprendido al encontrar en El Comercio un aviso buscando programadores que manejaran assembler, con el cuál yo había estado jugando/descubriendo desde hacía pocos meses. Por supuesto que fui y en verdad estos tipos sabían del asunto, se hacían llamar "Software Home" y antes que nada me pidieron que mostrara lo que había hecho (un muy simplón juego de serpientes come-números, pero escrito en assembler, que me había costado sangre!). Espero haberles causado una buena impresión, el hecho es que luego me mostraron lo que estaban creando y fue impresionante! Un video juego a la altura de los que llegaban del extranjero. Por diversas razones luego de un tiempo no supe más de ellos. Otros como TEG (hoy Tegmo.com) continuaron la pelea.

Todo ese mundo murió con la masificación de las PCs y terminamos simplemente consumiendo software pirata.

Lo que no he perdido es la convicción de que más que simplemente usar, se debe crear. Por eso VIS emplea su propio framework, para poder controlar cada aspecto a nuestro antojo. Desde hace casi 10 años lo hemos usado para incontables proyectos en diferentes encarnaciones y nos ha permitido diferenciarnos y poder transferir a cada cliente, la experiencia del proyecto anterior, siempre mejorando nuestro arsenal de herramientas.

Esperemos que el tema comercial no termine -otra vez- convirtiéndonos en simples consumidores. En nuestro medio es muy común "seguir a la manada", usando siglas, abreviaturas, etc. casi como alarde de que supuestamente conocemos un tema. Aquí los "monstruos en computación" usan Firefox, instalan Linux, recompilan Kernels y hasta "hackean" messengers :) pero son contados los que realmente entienden por qué lo hacen, menos aún los que modifican código o crean patchs. Ni qué decir de creaciones propias.

Mi pesadilla con phpMyAdmin sobre IIS 7

El título puede resultar decepcionante no? Instalar phpMyAdmin es un juego de niños! o al menos siempre ha sido así para mi hasta HOY, pero finalmente luego de más de 5 horas encontré la solución. Y no me tomó mas que apenas 5 segundos.

La receta fatal es esta:
Windows 2008
IIS 7
MySQL 5.0.5
PHP 5.3.1 (FastCGI)
phpMyAdmin 3.2.5

Configuras phpMyAdmin, todo OK. Luego entras al login, luce perfecto, escribes tu login/pass y.... esperas, esperas, esperas una ETERNIDAD hasta que te aparece HTTP Error 500 con el MUY UTIL mensaje "ha ocurrido un error interno" :) Haces de todo, pruebas permisos, versiones, hasta le activas el Trace al IIS, nada de nada.

...pero al final del día, la culpa de todo la tiene el chin... digo... Windows 2008 :)

LA SOLUCIÓN? Probablemente tu config.inc.php incluye "localhost" como nombre de servidor MySQL, pero resulta que en Windows 2008 ese nombre no existe (está comentado en el archivo hosts). No me he tomado la molestia de averiguar por qué aún. Así que con tan sólo cambiarlo por "127.0.0.1", EUREKA! todo funciona de maravillas!

Ojalá esto sirva para salvar a alguien del martirio que tuve hoy.

FTP Pasivo con Windows 2008

Clásico problema: quiero conectar el Filezilla a uno de nuestros nuevos servidores con Windows 2008 y no funciona como Pasivo, sólo como Activo. Reviso el firewall y tiene una regla para el FTP que obviamente funciona con el modo Activo únicamente.

Luego de buscar un poco por internet encontré estas casi mágicas líneas:

netsh advfirewall firewall add rule name="FTP (no SSL)" action=allow protocol=TCP dir=in localport=21

netsh advfirewall set global StatefulFtp enable

La primera se ocupa del puerto 21 y la segunda del StatefulFtp que aperturará dinámicamente los puertos necesarios para el FTP Pasivo.

IIS SMTP Service en localhost:25

Ok, quizá sea uno de pocos con tal necesidad porque busqué un buen rato en Google sobre el asunto sin tener éxito.

La cuestión es simple: cómo configurar el SMTP Service del IIS para que sólo responda por el IP 127.0.0.1 (localhost) puerto 25 de modo que podamos tener otro programa en la interface pública, en el mismo puerto, recibiendo los correos que llegan de afuera?

La idea es que el IIS SMTP atienda a las aplicaciones en ASP o PHP que suelen apuntar directamente al localhost:25, dejando libre las interfaces públicas para darles otro uso.

En principio usando el MMC no se puede, porque la dirección 127.0.0.1 no aparece en la lista.

La solución es muy simple: sólo se debe editar la Metabase (generalmente c:\windows\system32\inetsrv\metabase.xml) con notepad o algún otro editor de textos y reiniciar el IIS. Incluso no es necesario reiniciarlo si se tiene activa la opción de poder editar la metabase directamente, ya que en ese caso el IIS detecta que ha sido alterada y la recarga automáticamente sin reiniciar.

Primero, ubicar la línea:
<IIsSmtpServer Location ="xxxxxxxxxxx"

Y desde ese punto buscar:
ServerBindings=":25:"

Lo más probable es que tenga ese valor (":25:") y todo lo que hay que hacer es dejarla así:
ServerBindings="127.0.0.1:25:"

Luego cerramos el editor, cerramos el MMC (si lo teníamos abierto) y si lo reabrimos veremos que la dirección 127.0.0.1 ya aparece como una interface más y por supuesto, ya seleccionada.

Me ha funcionado muy bien. Ahora tengo el IIS SMTP respondiendo sólo por localhost mientras otra aplicación de filtrado de spam recepciona correos entrantes.

UPDATE 12/Feb/2010:

No funciona más. Con Windows 2008 no resulta, parece que internamente la validación es más estricta y por más que pongo el IP del localhost, en el IIS Manager aparece asignado a todas las interfaces. Al final tuve que asignarlo a otro puerto, elegí el 587. En el IP original está el otro servicio SMTP que acepta relaying del localhost, así que funciona bien. Despues de todo el 587 sólo queda para CDONTS o CDO.

4 días bajo ataque

Desde que empezó esta semana nuestros servidores han estado recibiendo MILES de conexiones SMTP. Al principio fue un gran problema ya que saturaba las conexiones (denegación de servicio) causando que nuestros clientes no pudiesen enviar correos.

Tratamos de analizar la fuente, buscar un patrón, NADA. Totalmente aleatorio. Los IPs cambian todo el tiempo y siempre intentan lo mismo, autenticarse mediante fuerza bruta, probando miles de combinaciones de login/pass. No sabemos si es un virus, spam o algo parecido, al fin y al cabo da lo mismo.

En medio de todas las cosas que tenemos que hacer, tuvimos que hacer espacio para resolver este problema y hemos tenido éxito!

Por suerte el software de correo que empleamos es extremadamente flexible: qmail, vmailmgr, courier-imap, mailfront, mrtg, daemon-tools. Combinados nos han permitido contener el problema en niveles que permiten que nuestros servicios se mantengan operativos.

Empezamos con algunos scripts para ayudarnos a rastrear las fuentes y bloquearlas. Su efecto no duraba mas que unos minutos y de nuevo volvíamos al DoS (Denial of Service). Poco a poco lo fuimos mejorando, hasta que ahora corre cada 5 minutos, analiza los logs, extrae los IPs que dan error de autenticación y los coloca en una lista gris, los compara contra los IPs que sí se han autenticado y los coloca en una lista blanca. Luego procede a bloquear todos los IPs de la lista gris que no estén en la lista blanca. Mantiene un registro de las últimas 24 horas de actividad de modo que los IPs no vuelvan a ser reutilizados en poco tiempo.

A esta hora tenemos bloqueados más de 2000 servidores, de diferentes partes del mundo, principalmente Brasil (famosos por siempre aparecer primeros en las listas de países con servidores zombies).

Hemos investigado en internet si hay "algo" al respecto pero no hemos encontrado nada, no creo que seamos los únicos con este problema!!!

Por ahora, vamos pasando bien la tormenta, van 4 días!!!