Parece que Google, la todoperosa que pretende.dominarnos a todos ha tenido que enseñar músculo ante el arrecio de la no menos grande, al menos en tamaño porque en ideas, no, Microsoft.

Sucedió hace un día, Microsoft lanzó ayer su Office 365, en clara competencia a las Google Apps ambas aplicaciones ofimáticas para trabajar en la nube, vamos, lo que se lleva tanto ahora incluso después de los ataques hackers a Sony y compañía.

Ha sido Shan Sinha, el Google Apps Product Manager quien ni corto ni perezoso se ha currado un post comparando ambas aplicaciones web, donde curiosamente deja a Office 365 a la altura del BITún.

En resumen y a destacar en esta batalla de declaraciones cruzadas, a día de hoy la solución ofimática en la nube de Google es netamente superior pues tan sólo la especificación multiusuario y colaborativa de la misma ya la hace desde mi punto de vista ganadora.

Por ejemplo yo creo documentos de texto y hojas de cálculo que comparto con mis clientes en un par de clicks. Ahora bien aunque suene muy bien en la práctica tiene un pero muy grande, tanto el compartidor como los compartinentes, menudo palabro, deben disponer de una cuenta de Gmail.

En otro parámetro que a mi modo de ver Google Apps aventaja a Microsoft Ofice 365 es en que la primera es multiplataforma, esto es, Windows Mac Linux y tablets. En cambio Office 365 parece que no lo es.

Luego viene el defecto endémico que Microsoft comete una y otra vez con el sistema de licenciado.de sus productos, según leo hasta 11 versiones, cifra que me provoca rampa en los ojos de sólo pensar lo que hay que leer antes de decidir. Esto debe ser una decisión en busca del agrado corporativo, de otro modo no lo entiendo.

Aún así, con las Google Apps como claramente ganadoras al menos en los primeros embites de este nuevo combate entre líneas se ve a Google.asustada…

http://googleenterprise.blogspot.com/2011/06/365-reasons-to-consider-google-apps.html?m=1

Hoy os presento un caso raro y de aquellos cansinos, un cliente con un servidor web ya con añitos, corriendo Windows 2003 Server parcheado hasta la médula, un día se enlentece que da miedo, este servidor recibe ciertos bots que sniffan literalmente todo su contenido, que no es pequeño llegando a generar con ello tráficos mensuales más allá de los 20 gigas. La mitad de los cuales se lo reparten entre bots snifadores y los spiders indexadores de la red, léase GoogleBot, Yahoo Crawler, Microsoft Search y sucedáneos rusos.

Casi siempre todo funciona bien, el servidor es robusto y responde sin muchas preocupaciones pero el problema llega cuando uno de estos robots se vuelve loco. Seguramente esta locura es producida por algún cambio en alguna variable que fuerza el número de escaneados diarios que realiza el bot, de esa forma el humano “snifante” prueba con diversos valores subiendo a veces sin saberlo la cantidad de peticiones por minuto de forma exponencial, el no ve las repercusiones en el servidor de origen, probablemente se dice, que bien ahora así tengo el contenido nuevo tan pronto como se publica, si soy el primero posiciono mejor, lo voy a dejar así. Y sin saberlo está haciendo un ataque DDOS o de denegación de servicio.

En este caso concreto es tal el consumo que en hora punta de tráfico las peticiones se enletecen hasta más allá de los 3 segundos por página peticionada.

Lo primero es detectar que algo paso, esto por suerte te lo dicen los clientes del servicio web en cuestión con emails técnicos del tipo:

“La web va lenta”, “La web va como el c…”

Recibido el tercer email de este tipo y tras comprobar que no es un problema de la conexión del cliente hacia la red, que también reportan, toca averiguar que está pasando.

1. Vemos el estado de saturación de la máquina. En Windows con el Administrador de Tareas.

2. Lo primero es ver que tal estamos de RAM, que consumo tenemos.

3. Luego vemos el espacio en disco que nos queda

4. El consumo de CPU

5. Ahora vamos a ver con ese mismo administrador de tareas que “programas” son los que más consumen

Si es MYSQL y la RAM va cargada tocará ampliar RAM, al igual de que si es disco.

Si es APACHE y la CPU va saturada, pues tocará ver cuantas peticiones y de quien son recibe el servidor web.

Para conocer cuantas peticiones recibe nuestro server hay muchas cosas y programas, pero en este caso no hay ningún sistema estadístico instalado, bueno si, Google Analytics, el cual pinta y colorea los datos que da gusto, pero a nivel técnico no nos sirve pues estamos buscando excesos y errores y me da a mi que Analytics los obvia, a saber porque con la todopoderosa y sus manías, que ya me cansan.

Aunque no tengamos nada instalado en server siempre nos podemos bajar los archivos de log del Apache para analizarlos en casita, con nuestra maquinita.

Ten en cuenta que estos archivos pueden ser gigantes, depende de como esté configurado el server, los hay con rotaciones y sin, pero puedes encontrartes con archivos de 2Gb. en servidores de alto tráfico, lidia con ellos si puedes. Lo mejor es rotarlos manualmente en el momento de máximo tráfico o ataque.

Para ello, detén el servicio de Apache, renombra los access.log y error.log y vuelve a iniciarlo, dejarás a tu cliente sin servicio un minuto escaso. Aguanta un ratito con el ataque, un par de horas a lo sumo, y vuelve a hacer lo mismo, de esa forma tendrás una muestra sanguínea del ataque o del momento de saturación del server y trabajarás única y exclusivamente con esos datos, localizando más rápidamente si existen direcciones IPs que un consumo excesivo de datos.

De Windows a Ubuntu y tiro porque me toca

Una vez muevas ese log a una carpeta accesible por FTP o HTTP faltará bajártela para analizarla en tu flamante workstation Ubuntu, que mola más que un OS X… al menos más que un Snow Leopard, pues falta ver si este próximo lunes día 6 de Junio lo que nos maravilla OS X Lion de la mano de Steve Jobs, palabra de AppleFun arrepentido venido a Ubuntu.

Analizando los archivos .log de Apache

Para analizarlo en nuestro Ubuntu vamos a usar Webzilla, para instalártela:

sudo apt-get install webalizer

Luego la configuramos con un:

sudo gedit /etc/webalizer/webalizer.conf

Aquí en principio sólo falta tocar el lugar, ruta y archivo donde está el access.log

LogFile                   /var/www/logs-para-analizar/access.log
OutputDir              /var/www/webalizer
Incremental           yes

Grabamos y ejecutamos el Webalizer con un complejísimo, es broma:

sudo webalizer

Unos segunditos y tachán, apunta tu navegador a:

http://localhost/webalizer

Selecciona el mes actual, y en la siguiente pantalla la opción “Clientes” aquí verás las IPs que han visitado más la página durante el ataque o la bajada de rendimiento del server, busca las más abultadas que vamos a revisarlas.

Ahora nos faltará saber el Quién es quién de cada IP

¿Quién es quién?

Para eso podemos usar varias opciones, entre ella una via web:

http://whois.domaintools.com/67.195.112.52

Donde 67.195.112.52 es la IP sobre la que quieres conocer información y la otra es usar las herramientas de red del sistema que incorpora Ubuntu.

Con ellas puedes realizar un WHOIS, un LOOKUP , etc.

Si entras en “Explorar los puertos”, cosa que tarda un rato podrás también detectar si detrás hay un servidor web, un servidor FTP, o un emule abierto. Datos que te permitirán determinar con algo más de certeza si se trata de una empresa o un usuario.

También puedes rastrear la ruta para más o menos ver de donde es el país de origen, si este por ejemplo es de Ukrania o de la conchinchina probablemente se trate de un buscador en el que no te importe perder posicionamiento.

Cuidadín cuidadín con los GoogleBots y familia

Pues eso, asegúrate que de todas esas IPs no te apuntes ninguna que sea de un buscador conocido en el que te quieras posicionar, pues si la anotas y luego la baneamos perderás el posicionamiento en ese buscador pues tu Apache no le dejará entrar.

Ya tenemos las IPs localizadas y correctamente anotadas, ahora vamos a banearlas

Baneando IPs en Apache bajo Windows

Bueno esto a decir verdad es más o menos igual en Windows que en Linux que un radiocassette donde sea capaz de correr Apache.

Busca el fichero de configuración de Apache httpd.conf

En la sección Directory

Introduce al final, justo antes del cierre de la directiva </Directory> y una en cada línea la siguiente instrucción:

deny from TU-NO-PASAS

por ejemplo si quisiéramos banear a Yahoo, NO lo hagas!

deny from 67.195.112.52

Graba el fichero y reinicia Apache, en Windows desde “Accesorios -> Herramientas del Sistema -> Servicios -> Apache” botón de la derecha reiniciar.

Listas negras de IPs malignas

También de paso y por el mismo precio que nos ponemos a banear, una práctica aceptable sería el banear sistemáticamente aquellas IPs que se han detectado en el mundo recientemente como IPs malignas.

Yo he sacado una lista desde:

http://isc.sans.org/ipsascii.html

y desde:

http://isc.sans.org/sources.html

Baneando que es gerundio.

Grr, grr, grr. Google Please API existe?

Me entero ayer y exploto en ira hasta el día de hoy de que la todopoderosa ha decidido echar el cierre a la API de Google Translate, así porque sí, porque las razones que esgrimen en su blog sólo serán creíbles para los que no entienden o para los más estúpidos.

Estos de Google se creen que somos purria, que los pequeños freelances estamos para servirles en todo y hasta cuando quieran, y lamentablemente parece que así es, si no mirad como bajamos la cabeza año tras año con la esclavitud a las que nos somete el gigante de mountain view con sus logaritmos mutables de búsqueda, nuevos métodos que para mi han dado un paso atrás en la cordura de los resultados resultando ser cada día incluso un poco más absurdos, putos bots!

En el cierre de Google Translate API esgrimen que hay un exceso de uso, pues señores, con una API lo tienen ustedes muy fácil para controlar el uso y abuso que hace cada usuario para poder limitarla a su antojo. Desde establecer un número máximo de peticiones diarias, bloqueo de usuarios que realizan SPAM, buff son infinitos los métodos que te provee cualquier API para contabilizar y controlar a placer a los usuarios, más cuando eres el que supuestamente la desarrolla, además antes de cerrar la API de traducción piensen que si existe un supuesto “abuso” en la utilización de esa API quizá esto se debe a que existe la necesidad de traducir, además por fin tienen una herramienta verdaderamente práctica y enfocada a los powerusers, a los programadores web, que pueden ser profetas suyos o enemigos. Quizá querrán que usemos y les testeemos de forma totalmente altruista aquello que les venga en gana, léase Waves, Buzzes y demás patrañas, que no se usan porque para poco o para nada sirve. Váyanse a tomar el pelo a un calvo!

También veo otras muchas soluciones antes de testeronizar su decisión, y quitarla porque me sale de aquí en medio, desde introducir un copyright sobre la traducción o un adSense, hasta cobrar por su uso, tarificar señores, tarificar que seguro que de eso saben un rato, no lo se, piensen ustedes soluciones inteligentes, que no insulten y que les engrandezcan en la comunidad de desarrolladores que para algo son una megaempresa de alta alcurnia.

Seguro que has notado que estoy de color rojo vivo y algo cabreado, pero es que todo esto me sucede la misma semana que he desarrollado y aplicado, dedicando casi la totalidad de la semana al desarrollo y testeo, una funcionalidad a mi motor de tiendas virtuales ecoommerce.com a través de la cual el sistema se encarga de traducir los productos hasta cinco idiomas diferentes. Utilizando la Google Translate API. Una API que ya tiene fecha de caducidad, el día 1 de Diciembre del 2011 se desconectará. Motivos tengo y este es mi blog y en él suelto lo que quiero.

Ahora toca buscar alternativas, lo primero es vender mis acciones de Google, que las cuento por millares… HGP! otra coger el primer vuelo hacia los U.ES.EI y plantarme en la puerta de la central de la todopoderosa y no dejar pasar a ningún ejecutivo corbatero capador, que se lleva mucho; hasta comenzar a buscar en Google la cadena “Google Please API” de forma que vean en sus logs nuestro mayúsculo mosqueo.

Pero como siempre lo que tocará de verdad y a partir de mañana lunes es a buscarse la vida, otra y otra vez.

Quizá la solución venga de la perversa Microsoft:

http://msdn.microsoft.com/en-us/library/ff512423.aspx

O bien algunas otras API que veo en programmable web:

http://www.programmableweb.com/apitag/translation

Conocéis alguna de estas APIs?