Concretamente nos va fastidiar un 1% del tráfico que a su vez se traducirá en una pérdida de un 10% o más en los ingresos en publicidad pues nos va obligar a desplazar los primeros bloques de publicidad sea adSense u otra más abajo de la cabecera, probablemente fuera de scroll.

Y esto nos lo van a pedir cuando ellos, los muy aneutrales meten sus adWords arriba pero arriba del todo, doble rasero, doble moral que nos recuerda la cada vez más insoportable dictadura a la que nos someten cada dís, ellos dictan y nosotros copiamos.

Ya no es que cada vez resulta menos rentable mantener un blog que se nutra sólo de la publicidad sino que al final sólo van a quedar los grandes medios porque una empresa monopolista parece que así lo quiera.

¿Trabajamos para ellos? Parece que sí y que cada vez más, yo por lo pronto me cago en mountain view.

http://googlewebmastercentral.blogspot.com/2012/01/page-layout-algorithm-improvement.html

Páginas relacionadas con este artículo:

1. Pon tu publicidad en Pixmanía
2. Ganarse la vida con publicidad 1
3. Publicidad en el móvil

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.

Páginas relacionadas con este artículo:

1. Test de carga web
2. Personalizar un virtual host de Apache bajo Plesk
3. Bloquear muchos intentos fallidos de acceso a servidor

Tanto es así que me voy a ir dejando algunos post con las cositas que más me han costado configurar, porque la información que popula por la red a es tan maravillosa como incompleta, equívoca en muchos casos.

El servidor FTP que he tenido el placer de configurar a pelo no es otro que Proftpd y si bien lo he realizado desde un Ubuntu, cualquier distribución linux puede utilizarlo, la diferencia es mínima.

Instalarlo es la mar de sencillo a la par que barato, desde un terminal copiaypastea el siguiente palabro:

sudo apt-get install proftpd

Luego creamos una Shell falsa editando el archivo de shells con vuestro editor favorito, en mi caso nano, el Vim para los suelos, que los deja como el oro (broma, con poca gracia, todo hay que decirlo, en modo años 80)

sudo nano /etc/shells

Aquí añadimos lo siguiente al final del texto, tal cual

/bin/false

Nos aseguramos de tener creados los directorio de subida de ficheros, en nuestro caso están en: /var/www/miftp

Si tenemos que crear el directorio recuerda:

mkdir /var/www/miftp

Luego dale permisos de lectura y escritura, los famosos 777

sudo chmod 777 /var/www/miftp

Ahora vamos a tocar un poco el archivo de configuración general de ProFTPd para ello volvemos a ejecutar el editor nano:

sudo nano /etc/proftpd/proftpd.conf

En nuestro caso aquí hemos tocado bien poco, tan sólo hemos cambiado el usuario de proftpd por nobody, busca “user” que estará justo antes que “group” y allí cámbialo, para buscar en nano utiliza CTRL+W

Graba el archivo con un CTRL+O Enter y continuamos

Ahora vamos a añadir un usuario FTP en Proftpd, aquí es donde los diferentes blogs que he consultado la lían parda, te meten un comando useradd con tres parámetros básicos, nombre de usuario, clave y directorio, pues bien, la clave, la clave, la clave de las pelotas debe ir encriptada, de lo contrario todos los intentos de login contra el servidor de FTP serán del todo improductivos. Al final en un foro he visto la luz, tal es así que vamos a realizarlo nosotros en dos pasos, en dos líneas de comandos en lugar de una, la primera sin la clave y la segunda con el encriptador de claves.

useradd –d /home/ftp pepepalotes

Y ahora el encriptador que no es otro que el comando pasword de linux:

passwd pepepalotes

El sistema te pedirá la clave, la introduces tal cual y ya se guardará encriptada.

Ahora reniciamos el servicio de FTP con el siguiente comando y a conectarse!

sudo /etc/init.d/proftpd restart

Páginas relacionadas con este artículo:

1. Instalar archivos .bin en Ubuntu
2. Habilitar cURL en Ubuntu
3. Desinstalar kernels antiguos en Ubuntu

No se si es porque no me leo la documentación de nada de cabo a rabo, de ser así probablemente estaría leyendo aún los manuales de la PalmPilot I, o siendo sinceros los del ZX Spectrum pero el modulito mod_pagespeed que lanzó Google me ha dado por saco durante horas, deteniendo mi producción “pa na”.

Os explico a continuación, me lo instalé hace unos días en mi máquina con Ubuntu donde desarrollo aplicaciones web como siempre para trastear con ello y ganar algo de velocidad en descarga, pues bien en esta máquina es donde mismamente estoy mejorando el sistema de emailing que incorpora mi aplicación de facturación electrónica invOOice.com.

Con este modulo instalado, que debe ir de narices para máquinas en producción, Apache2 te crea un directorio donde cachea ficheros estáticos, por ejemplo los ficheros .js con javascript, luego al hacer cambios y grabarlos, Apache2 no se entera durante un cierto tiempo y el problema es que cambias y no ves los resultados producidos por el cambio, todo esto durante horas hasta que al final con un alert(‘hola hola’) que no aparecía por ningún lado me di cuenta de que esto leía de algún sitio que no era el suyo, nada, ves el código fuente, te fijas y tachán:

forms.ajax.js.pagespeed.ce.QB8x0iVrtt.js

Grrrr… ahora ármate de valor baja a la línea de comandos y desinstala el módulo pagespeed, eh? bueno, pues para eso os copio aquí la solución, a grandes trazos borrar los módulos a saco paco del directorio de módulos de apache:

cd /etc/apache2/mods-enabled/

rm pagespeed.conf

rm pagespeed.load

y reniciamos Apache con un!

/etc/init.d/apache2 restart

Te quedará una carpeta en apache2 con los cachés, yo no la he borrado, en cuanto pueda volveré a experimentar con pagespeed pues se notaba bastante, pero por el momento vamos a lo que vamos.

Páginas relacionadas con este artículo:

1. Habilitar cURL en Ubuntu
2. Habilitar cURL en Ubuntu
3. Instalar Apache 2 PHP 5 MYSQL 5 y Webmin 1.5

¿Qué es lo que está pasando?, la venerable web de SlashDot, propietaria del famoso Efecto SlashDot, por el cual te fusilaban la web a base de fosfocientas mil peticiones per second, ya no acepta que añadas enlaces.

Esta web se estaba quedando anticuada, era un websaurio almidonado hasta la cresta, vaya, que no la visitaba desde tiempos inmemoriables pues su home ya me dejaba cierto tacto rancio y una honda tristeza. Pues si no tenía bastante la pobre, ahora más con esto de no dejar más bookmarqueos, por lo que de momento le ponemos la cruz de sitios a los que no visitar. Pues si ya no se nutre de los bookmarks de los powerusers creo que ya no tiene nada que ofrecerme.

Os dejo aquí el enlace que me ha llevado el error, es un enlace de esos que sirven para postear en SlashDot de forma semiautomática.

http://slashdot.org/bookmark.pl?title=Tu%20Twitter%20tiene%20m%C3%A1s%20relevancia%20que%20tu%20web&url=http%3A%2F%2Fuvedobles.com%2Ftu-twitter-tiene-mas-relevancia-que-tu-web%2F

Páginas relacionadas con este artículo:

1. Test de carga web
2. ¿quién habla de mi web?
3. Hemerotecas de prensa española

Cada día, cada mañana a primero hora y tras arrancar mi máquina Ubuntu, este mensaje me da los buenos días:

Introducir la contraseña para desbloquear el depósito

Esto me sucede desde que cambié la contraseña de mi usuario, y viene a decirte que esta no coincide con la contraseña del Keyring o anillo de llaves. Es decir, la contraseña del llavero, la contraseña de las contraseñas.

Así que finalmente y tras casi un mes decidí buscar una solución al respecto, una solución tan fácil como:

sudo aptitude install libpam-keyrin

Páginas relacionadas con este artículo:

1. Tecla mayor que menor que teclado Apple
2. Recuperar archivos borrados en Ubuntu
3. Problema películas DVD Ubuntu Karmic Koala

Bueno, este post es un tip, para aquellos locos que teniendo un Mac prefieran Ubuntu, y cada día son más, o para aquellos que teniendo un Mac, se venden todo los Mac y se pasan a Ubuntu, territorio de libertad, y cada día somos más, pero que se quedan ese bonito teclado de aluminio con teclas ultrabajas que te hace volar… y que ocupa poco, poquito en tu mesa de trabajo.

Ese teclado de aluminio, que en su día compré por unos 60 euros, ya ves como se las gastan los de la manzana, no funciona del todo bien bajo sistema operativo Ubuntu, intercambia las teclas “><” de al lado del Shift temporal por “\” la de al lado del “uno”, cosa que en principio puede no resultar preocupante, pero que si eres programador te proporciona demasiados momentos de sulfuro, y ganas de tirar el eso sí, bonito teclado, por la ventana.

Pues bien, tras tres largos segundos intentándom acostumbrar a ir a buscar esos signos, tan propios de mis sentencias IF bajo PHP, lejos, por allá arriba de mi teclado Eipel, me desesperé y comencé a buscar la solución por la red, un minuto después… <>>< toma! toma y toma!

Si quieres compatibilizar tu teclado Apple con tu Ubuntu Para empezar ves a Sistema > Preferencias > Teclado y seleeciona Apple Aluminium Ansi, luego te vas a un terminal y como superusuario:

sudo -s

Crea el archivo:   “.Xmodmap” sin las comillas en tu directorio Home

sudo nano .Xmodmap

Añade estas líneas:

Reinicia sesión, y prueba.

Si no quieres reiniciar sesión también puedes hacer un:

xmodmap -e “keycode 49=less greater” && xmodmap -e “keycode 94=backslash bar”

Lo que este último es un cambio sólo temporal, es decir, en cuanto reinicies lo pierdes.

Páginas relacionadas con este artículo:

1. Nuevos portátiles de Apple MacBook Pro
2. Representar teclas del teclado
3. Chuleta con atajos de teclado para Photoshop

Hoy desde la playa y bajo un imperoso sol os dejo un enlace donde nos invitan a someter a rigurosa dieta a nuestras bases de datos, es obvio y todos ya lo sabemos, pero el autor del post original lo ha medido y cuantificado, dale!  http://af-design.com/blog/2009/02/24/a-smaller-database-is-a-faster-database/

Páginas relacionadas con este artículo:

1. Base de datos Cassandra
2. Optimizar servidor MySQL
3. Instalar Apache 2 PHP 5 MYSQL 5 y Webmin 1.5

Menudo bugazo de MySQLos hemos encontrado hoy! Este bug porque sí, porque lo es ya que tiene toda la pinta de ser un bicho nos ha traído de cabeza durante dos días. Si ya pensaba yo que esto de que Oracle salga de compras no nos iba a traer nada pero nada bueno, en fin webmaster of the universe os ponemos en antecedentes:

Estamos ultimando la v.3.9 del sistema de tiendas online ecOOmmerce.com en ella hemos incorporado una función que realiza las actualizador de precios y de stock semiautomatizado donde el cliente en base a un fichero bajo formato .csv (parecido al excel, realmente es un txt con campos separados por un signo) puede desde el backoffice de la aplicación actualizar los precios de una tacada.

El servidor web alojado en Hispalab corre Linux con Mysql versión 5.0.90 instalada. Nosotros disponemos acceso al Cpanel para administrar, si bien no podemos acceder a consola por SSH ni a través de Cpanel.

Intentamos hacer un típico LOAD DATA LOCAL INFILE para cargar datos de un fichero .csv en una tabla temporal de la base de datos que posteriormente será analizada por nuestra nueva función y actualizará los precios.

La sentencia es la típica, reportada en cientos y cientos de foros de desarrollo tanto en español como en lengua sajona:

LOAD DATA LOCAL INFILE ”/home/dominios/test/public_html/tmp/tarifatest.csv” INTO TABLE table01 FIELDS TERMINATED BY “;” LINES TERMINATED BY “\n”

Y desde la aplicación no recibimos error alguno, para acotar el tema vamos al Phpmyadmin a través de Cpanel y copypasteamos el comando, automáticamente nos escupe el siguiente error:

#1148 – The used command is not allowed with this MySQL version

Repasamos la sentencia de SQL mil quinientas veces y es entonces cuando el ingeniero de sistemas de Hispalab nos dice que no utilicemos el “LOCAL”. Nos documentamos y si, una vez el archivo está en servidor no hace falta utilizar el argumento “LOCAL” ahora bien, al modificar esta función nos encontramos con otro nuevo error:

#1045 – Access denied for user ’wwwtest’@'localhost’ (using password: YES)

Así que comenzamos primero desde PHP y luego desde FTP (no tenemos acceso a consola) ha realizar todo tipo de CHMODS y CHOWN para cambiar los permisos y propietarios de el archivo y la carpeta subida. No conseguimos nada más que perder el tiempo.

Desolados reportamos a Hispalab y al final y tras casi dos días de darnos cabezazos contra el teclado alguien vio la luz en Hispalab, ese LOCAL, ese LOCAL, lo probó en minúsculas “local” y… como bien dijo el “zasss…. todo funcionó”.

Impresionante, ni en la propia documentación de MySQL figura ni una sóla vez en minúsculas, puedes verlo en:

http://dev.mysql.com/doc/refman/5.1/en/load-data.html

En fin, hay queda este post por si alguna vez oss encontráis con semejante problema.

Páginas relacionadas con este artículo:

1. Optimizar servidor MySQL
2. Aplicación web PHP para backup de mysql
3. Cambiar clave root a Mysql por línea de comandos Windows

El RSS es un sistema que en marketing se agruparía dentro de los PUSH, pues es el RSS el que va a buscar al usuario, obviamente una vez este se ha suscrito, la página web en sí es un método PULL donde al contrario que en los PUSH es el usuario el que tiene que ir a buscar la información con su navegador.

No vamos a entrar en este artículo a hablar de las numerosas bondades del RSS pero sí que vamos a ver un sencillo y práctico validador de RSS online.

Para comprobar si un determinado Feed cumple con las reglas de dicho formato existen muchas opciones, algunas de escritorio pero para nosotros la mejor es Feed Validator, una aplicación online que te validará cualquier dirección de internet que contenga un RSS. Toma buena nota de la dirección: http://beta.feedvalidator.org/

En la captura anterior, hemos realizado la prueba con un cliente nuestro, cablematic.com donde hemos colocado un nuevo generador de RSS para todas y cada una de las familias de productos, al intentarlo validar podemos ver diversos errores detectados en la estructura del FeedRSS, el primero y realmente importante es la utilización de signos [] también denominados brackets en el tag interno del title de la noticia del RSS.

Para evitar este error hay que escapear la salida de todos los textos, míra como lo hemos realizado:

$rssOutput .= ‘<title>’.'<![CDATA['.$lng_ref_min.' '.$productRef.' '.$productName.']]>’.'</title>’.”\n”;

Es decir  tras el tag ponemos el <![CDATA[ para segir con las variables que contienen el texto, en nuestro ejemplo 3 variables, la palabra REF. (acrónimo de referencia), la referencia del producto y finalmente el nombre, este último es que contiene brackets. después finalizamos con ]]>

El resto de errores que nos lanza Feed Validator no son errores como tal sino sugerencias para intentar compatibilizar el feed con el mayor número de lectores de RSS. Por ejemplo la primera nos informa de que existen demasiadas entradas con la misma fecha y hora. El segundo que para mejorar la compatibilidad no se incluya HTML dentro de los feeds, pero nosotros en este caso no buscamos la mayor compatibilidad si no que quien los vea los vea bien y a todo lujo de detalles, un producto bien presentado vende mucho más que uno que se vea con un Amstrad CPC a sólo texto.

Enlace: http://beta.feedvalidator.org/

Páginas relacionadas con este artículo:

1. Saber que es lo que tarda en descargar
2. ¿Qué se dice de mi sector?
3. Posicionar tienda online 1