A veces es necesario comprobar si el servidor que acabamos de instalar está enviando las páginas comprimidas con gzip si el navegador se lo solicita. La forma más sencilla es preguntándoselo con curl:

curl -I -H 'Accept-Encoding: gzip,deflate' https://rastreador.com.es

La opción -I hace que sólo nos muestre las cabeceras (petición HEAD)
La opción -H ‘Accept-Encoding: gzip,deflate’ envía la cabecera que le indica al servidor que queremos la página comprimida con gzip

Si entre las cabeceras que nos llegan aparece:
Content-Encoding: gzip
o
Content-Encoding: deflate

Significa que la compresión con gzip está funcionando.

Para eliminar la limitación de envío de emails de Amazon Web Service sólo tenemos que ir a la url:
https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

En esta misma pantalla también podemos solicitar al mismo tiempo la resolución inversa de dns asignando un nombre de host a la ip elástica que hemos asignado a esa instancia. Es muy recomendable hacer este paso para evitar problemas de spam.

aws_reverse_dns

Dentro de un par de días cambiaremos el IVA del 18% al 21% y todos los que tenemos tiendas online tendremos que cambiarlo a las 00:00 no vaya a ser que nos entre alguna venta y nos la líe. Os voy a contar 3 formas distintas de cambiar el IVA de vuestra tienda.

1.- Desde el admin de Prestashop
Hay que ir a la pestaña de pagos -> Impuestos y editando el impuesto correspondiente se cambia. ¡Acordaros de cambiar el texto en todos los idiomas que tenéis activado!

2.- Desde Mysql
Para usar esta opción hay que saber usuario y contraseña de mysql y el prefijo de las tablas. Como prefijo he utilizo el que pone por defecto prestashop ps_
Desde mysql, phpmyadmin o similar ejecutar las siguientes ordenes

USE nombre_db;
UPDATE ps_tax_lang SET name=REPLACE(name,'18','21') WHERE id_tax=(SELECT id_tax FROM ps_tax WHERE rate=18);
UPDATE ps_tax SET rate=21 WHERE rate=18;

Desde bash los mas cómodo es hacer algo así:

mysql -u usuario_db -pclave_db base_de_datos_prestashop -e "update ps_tax_lang set name=replace(name,'18','21') where id_tax=(select id_tax from ps_tax where rate=18);"
mysql -u usuario_db -pclave_db base_de_datos_prestashop -e "update ps_tax set rate=21 where rate=18;"
También lo puedes automatizar en el cron y olvidarte del cambio.

3.- Con un pequeño script en php que puedes automatizar o ejecutar desde cualquier equipo.
Para poder utilizarlo debes de conocer los mismos datos que en la opción anterior y configurar el script con ellos.
<?php
	$host		=	'localhost';
	$user		=	'usuario';
	$pass		=	'password';	
	$database	=	'db_prestashop';
        $prefijo        =       'ps_';
 
        $sql1 = "update ".$prefijo."tax_lang set name=replace(name,'18','21') where id_tax=(select id_tax from ".$prefijo."tax where rate=18);";
        $sql2 = "update ".$prefijo."tax set rate=21 where rate=18;";
 
	$connect = @mysql_connect ( $host, $user, $pass ) ;
	echo "<h1>Proceso de cambio de IVA en la base de datos de prestashop</h1>";
	if ( $connect )
	{
			mysql_select_db ( $database );
			if ( @mysql_query ($sql1) )
			{
				echo '<p>Paso 1 OK</p>';
			}
			else {
				die ( mysql_error() );
			}
 
			if ( @mysql_query ($sql2) )
			{
				echo '<p>Paso 2 OK</p>';
			}
			else {
				die ( mysql_error() );
			}
 
	}
	else {
		trigger_error ( mysql_error(), E_USER_ERROR );
	}
?>

Si lo que quieres hacer es no repercutir la subida a tus clientes lo que hay que hacer es reducir el precio de los productos. La forma mas sencilla de reducir el precio de todos los productos es a través de una consulta SQL:

UPDATE ps_product SET price=price*0.975206611570248;

Espero que os sea útil.


80legs es un webcrawler que tiene la molesta costumbre de visitar todas las páginas de tu sitio web con cientos de visitas simultáneas desde diferentes direcciones ip con el resultado de que pueden llegar a tirarte abajo tu servidor, algo muy parecido a un ataque DDOS pero con barniz de legalidad.

La forma de identificarlos es revisando los logs del servidor donde podrás ver que el useragent de la visita es:
Mozilla/5.0 (compatible; 008/0.83; http://www.80legs.com/webcrawler.html) Gecko/2008032620

En su página te dicen que si no deseas que rastreen tu sitio web debes de añadir en el robots.txt lo siguiente:

User-agent: 008
Disallow: /

Mi experiencia es que muchas veces pasan olímpicamente del robots.txt o también puede darse el caso de que no puedas cambiar nada en ese fichero por lo que lo único que te queda para luchar con ellos es a través del servidor.

En mi caso el problema se me presentó en un servidor donde hay mucho tráfico y en el que utilizo cherokee como servidor web. Para solucionarlo lo que hice fue filtrar las visitas que me llegan con el useragent de 80legs.

Para hacerlo sólo hay que añadir una regla de tipo “header” con la cadena 008 ó 80legs.

Y después hacer lo que quieras con esas visitas: redireccionarlas a una página estática, mostrar un error (en el ejemplo un error 509 – Bandwidth Limit Exceeded – ó un 404 – página no encontrada – ) o simplemente mandarlos al carajo (un DROP).


Actualización
Si quieres bloquearlos desde un servidor con apache lo único que tienes que hacer es añadir estas líneas al fichero .htaccess de tu sitio web:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} (80legs)
RewriteRule ^(.*)$ – [F]

A veces puede ser muy útil asignar a un bucket o a unos ficheros en concreto dentro de un bucket una fecha de caducidad para tener controlado el espacio ocupado, especialmente si hablamos de backups o similar.

Desde la consola web de Amazon S3 se puede asignar esa caducidad muy fácilmente seleccionando el bucket sobre el que queremos trabajar -> propiedades y seleccionando la pestaña lifecycle.

Como podéis ver el funcionamiento es muy intuitivo. Se pulsa en “Add rule” y sencillamente indicamos si lo queremos activo, el nombre de la regla (opcional), el prefijo y la caducidad en días. El dato del prefijo es importante ya que indica sobre qué contenidos se va a aplicar esta regla, si no se indica nada, como en el ejemplo, se aplicará sobre todos los objetos del bucket. Si quisieramos que se aplicara sólo sobre los que están en la carpeta backup se pondría “backup/”, tened cuidado si no ponéis el slash “/” por que si tuvierais algún fichero que contuviera la palabra backup tambien se le aplicaría la regla, p.e.: backup_fotos_importantisimas.zip.

El borrado es diario y totalmente automático así que una vez grabadas las reglas nos podemos olvidar completamente de ese tema.

Si queréis profundizar un poco más en este tema os recomiendo leer la documentación de Amazon: http://docs.amazonwebservices.com/AmazonS3/latest/dev/ObjectExpiration.html


Este es un truco muy sencillo pero útil si necesitas cambiar el nombre del dominio de una tienda desarrollada con prestashop. Podrías cambiar de tienda1.com a tienda2.com o de tienda.com al subdominio mi.tienda.com

Se hace desde el mysql y sólo hay que cambiar los valores PS_SHOP_DOMAIN y PS_SHOP_DOMAIN_SSL de la tabla ps_configuration por el nombre del dominio o subdominio de la tienda. P.E.:

 

 

 

 

 

UPDATE ps_configuration SET VALUE="tienda.rastreador.com.es" WHERE name="PS_SHOP_DOMAIN";
UPDATE ps_configuration SET VALUE="tienda.rastreador.com.es" WHERE name="PS_SHOP_DOMAIN_SSL";

 

 
ACTUALIZACIÓN
Si usas un prestashop 1.5 o superior debes cambiar también estos registros:

UPDATE ps_shop_url SET DOMAIN='tienda.rastreador.com.es';
UPDATE ps_shop_url SET domain_ssl='tienda.rastreador.com.es';

Esta semana he tenido que migrar un servidor con plesk de un hosting normal (OVH en este caso) a una instancia de Amazon EC2.

Para la instalación inicialmente utilice una AMI de centos 6.2 y la última versión de plesk (10.4.4). Hice la migración del servidor antiguo al nuevo con la herramienta de migraciones del plesk y, con la excepción de unos errores sin importancia de la migración, parecía que todo estaba bien.

Normalmente suelo probar los dominios migrados modificando el fichero hosts de mi equipo antes de modificar las dns, por si algo no ha funcionado correctamente. En este caso fue muy buena idea ya que cuando accedías al dominio se veía la página por defecto de plesk, la del servidor, no la del dominio.
Evidentemente eso sonaba a que apache no tenía bien configurados los virtualhosts pero por más que miraba me daba la impresión de que todo era correcto.

Después de mucho probar y revolver, incluida una reinstalación completa de otra instancia y otra migración, esta vez con ubuntu server por si había algún problema con centos, di con la solución: el problema está en las ips del servidor y en como configura plesk los virtualhost.

Cuando se crea una instancia en Amazon se le asigna automáticamente una dirección ip privada del tipo 10.x.x.x y después tu le tienes que asignar una ip pública (elastic ip).

Cuando configuras las ips en plesk tienes que añadir a mano la ip pública al servidor y poner como compartida tanto la pública como la privada (10.x.x.x). En mi caso lo que estaba haciendo mal era que durante la migración seleccionaba como ip destino de la migración la pública y lo que debería de hacer era seleccionar la ip privada para que la configuración del virtualhost llevara esa ip. Debería de quedar algo así:

En vez de la fórmula habitual

Si ya has realizado la migración y no puedes/quieres volver a hacerla tienes dos opciones, o cambias a mano todas las ips o ejecutas un script como este para que lo haga por ti.

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -Ns -e “select name from domains;” | awk ‘{print “/usr/local/psa/bin/domain –update “$1″ -ip IP_PRIVADA_DE_AMAZON”}’ | sh

por su puesto que a mi me gusta mucho más la opción del script. =;-)

Tened en cuenta que si alguna vez paráis la instancia cuando la volváis a encender casi seguro que os habrá cambiado la ip privada y tendréis que volver a realizar todo este proceso. Es un problema que plesk no ha tenido en cuenta y que espero que solucione en próximas actualizaciones.

Otra de las incidencias que tuvimos en esta migración es que por alguna extraña razón el apache no hacía caso de la directiva DirectoryIndex y cogía siempre como fichero por defecto el index.html en vez del index.php, así que decisión salomónica: fuera todos los index.html,

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -Ns -e “select name from domains;” | awk ‘{print “rm /var/www/vhosts/”$1″/httpdocs/index.html”}’ | sh

Si utilizáis ubuntu server para la instalación lo mejor es que desinstaléis apparmor antes de empezar la instalación y si preferís dejarlo o no os acordáis hay que añadir a su fichero de configuración la siguiente línea para que bind os funcione correctamente.

vim /etc/apparmor.d/usr.sbin.named

y añadir

/var/named/run-root/** rw,

al final del fichero

Aunque no tiene nada que ver con Amazon si quieres cambiar el idioma del panel de control y la licencia que has contratado no lo permite lo puedes hacer directamente modificando un par de valores en mysql:

mysql -uadmin -p`cat /etc/psa/.psa.shadow`
use psa
update misc set val=’es-ES’ where param=’def_locale’;
update misc set val=’es-ES’ where param=’admin_locale’;

Si se me ocurre algún otro truco, o conocéis algún otro truco interesante, decídmelo y lo añadiré aquí para tener como referencia futura.

Prestashop es uno de los CMS de comercio electrónico que más auge está teniendo últimamente. La documentación es bastante buena pero hay algunas cosas que sólo tratan de pasada y creo que son muy importantes para mejorar el funcionamiento de Prestashop.

Concretamente os quería enseñar la forma de mejorar el rendimiento de prestashop utilizando Amazon CloudFront para servir contenidos estáticos.

Amazon CloudFront es el servicio de Amazon AWS que permite distribuir contenidos más rápido y con menor latencia que si lo hicieras desde tu propio servidor. Amazon CloudFront tiene distribuidos a través del mundo varios puntos de salida de forma que entrega los archivos al usuario desde el punto más cercano a su ubicación. Otra ventaja de Amazon CloudFront es que liberas a tu servidor de la entrega de esos ficheros con lo que consigues liberar recursos que podrás utilizar para otras cosas.

Para crear tu distribución lo único que tienes que hacer es ir a tu consola de Amazon y en la pestaña de CloudFront pulsar en “Create Distribution”.

Debes de seleccionar la opción de Custom Origin y en Origin DNS Name poner la página de tu tienda

En la siguiente pantalla debes de indicar un subdominio del dominio de tu tienda, aunque no es obligatorio. En mi caso lo suelo poner siempre por estética ya que si no cuando carga la página los clientes podrían ver que se cargan contenidos de otros sitios con nombres tan extraños como dlskfhxxxis3dhflk23shf.cloudfront.net. En el ejemplo he utilizado ccc1.mitiendac.com

En el último paso podréis ver como queda la distribución que acabáis de crear.

Una vez creada la distribución  podréis ver en el panel de control que hay una nueva distribución y que su estado es “InProgress”. En mi caso permaneció en ese estado unos 10 minutos hasta que pasó al estado “Deployed”  que es cuando ya se puedo empezar a utilizar.

En esta imagen tenéis un ejemplo de como quedaría.


Si habéis decidido utilizar un subdominio de vuestra tienda, mientras que finaliza la creación, podeís ir al servidor dns de vuestro dominio y añadir el subdominio a los dns. Para ello hay que crear una entrada cname con el nombre ccc1.mitienda.com. que apunte al nombre de la distribución que acabamos de crear, por ejemplo xxxxxxxx.cloudfront.net

El último paso es ir al administrador de prestashop y configurar el apartado de CCC (). Para eso hay que ir a Preferencias -> Rendimiento. y activar CCC. añadiendo la distribución. Si habéis utilizado el subdominio hay que poner ccc1.mitienda.com y si no, introducir directamente la distribución, p.e. xxxxxxxx.cloudfront.net en el apartado Servidores de media.

Como veis en la imagen se pueden añadir hasta 3 servidores de media. Para poner otros dos sólo hay que repetir lo anterior otras dos veces.

Por último os quería comentar algo sobre el coste de este servicio pero es difícil ya que es muy variable por que se factura en función del uso así que lo mejor es que vosotros mismos echéis mano de la calculadora y revisando los precios de la página de amazon lo calculéis o que utilicéis la calculadora de Amazon.

Si no os aclaráis con los precios lo que os recomiendo es que lo hagáis y que diariamente reviséis lo que lleváis gastado. Probablemente con el gasto de un par de días “normales” os será mas que suficiente para poder calcular el coste mensual.

Pandora FMS es un software de monitorización muy completo que estoy utilizando en sustitución de los icinga/nagios que venía utilizando hasta ahora. Una característica común a pandora fms y nagios es la capacidad de poder añadir tus propios plugins al sistema de monitorización lo que da una enorme libertad para poder hacer prácticamente cualquier cosa.

Uno de los plugins que he preparado sirve para poder medir con comodidad la velocidad de respuesta de un sitio web. Los parámetros que mide son:

  • Time to First Byte
  • Tiempo total de descarga
  • Tiempo de pretransferencia
  • Código http de respuesta
  • Tamaño total de la página

Algunos de estos parámetros son muy útiles para poder ver desviaciones o comportamientos extraños que asociados a su alarma correspondiente nos pueden avisar con tiempo para evitar caídas o incluso ataques.

Hay algunos parámetros que pueden extrañar como el código http de respuesta o el tamaño de la página, los he añadido para poder tener avisos de casos como errores 504 o 500 que de otra forma son difíciles de detectar y el tamaño de la página para monitorizar actualizaciones en ciertas páginas que no cuentan con herramientas como rss o similares para avisarnos de los cambios.

La instalación es muy sencilla y sólo se ha de copiar al directorio de los plugins del servidor donde tengamos pandora fms funcionando, asignarle permisos de ejecución y asegurarnos de que tenemos curl instalado (apt-get install curl).

En pandora debemos de ir a Gestionar servidores -> gestionar complementos y pulsar en Añadir y rellenar todos lo datos del plugin.


Ahora tenemos que añadir a un agente nuevo o a uno ya creado un nuevo módulo que utilice este plugin. El tipo de módulo debe de ser de Servidor de complementos.

Introducimos todos los datos necesarios, en este caso para medir el valor “Time to first byte”.

O por ejemplo para comprobar si se produce algún error 500 en una página

Este plugin está desarrollado en bash por lo que puede usarse desde la línea de comandos directamente.
Aquí os dejo el código fuente:

#!/bin/bash
# Page Speed Plugin Pandora FMS Server plugin
# (c) Manuel Angel Fernandez 2012
 
function help {
        echo -e "Page Speed Plugin for Pandora FMS Plugin server. http://pandorafms.com"
        echo " "
        echo "This plugin is used to check page speed and Time to First Time"
        echo " "
        echo -e "Syntax:" 
        echo -e "\t\t-f Time to First Byte"
        echo -e "\t\t-t Total time"
        echo -e "\t\t-p Pretransfer time"
        echo -e "\t\t-c Http status code"
        echo -e "\t\t-s Size download(Kb)"
        echo -e "\t\t-a All parameters csv format"
        echo -e "\t\t-h This help"
        echo -e "Samples:"
        echo "   ./page_speed -f www.yahoo.com"
        echo " "
	echo "by Manuel Angel Fernandez - manuel at rastreador.com.es" 
	echo " "
        exit
}
 
if [ $# -eq 0 ]
then
        help
fi
 
 
# Main parsing code
while getopts ":h:f:t:p:c::s:a:" optname
  do
    case "$optname" in
      "h")
                help
        ;;
      "f")
                curl -so /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" -w "%{time_starttransfer}\n" "$OPTARG?`date +%s`"
                exit 0
        ;;
      "t")
                curl -so /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" -w "%{time_total}\n" "$OPTARG?`date +%s`"
                exit 0
        ;;
      "p")
                curl -so /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" -w "%{time_pretransfer}\n" "$OPTARG?`date +%s`"
                exit 0
        ;;
      "c")
                curl -so /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" -w "%{http_code}\n" "$OPTARG?`date +%s`"
                exit 0
        ;;
      "s")
                curl -so /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" -w "%{size_download}\n" "$OPTARG?`date +%s`"
                exit 0
        ;;
      "a")
                curl -so /dev/null -H "Pragma: no-cache" -H "Cache-Control: no-cache" -w "Timetofirstbyte\tTotal-Time\tPretransfer-time\tHttp-code\tdownload-size\n%{time_starttransfer}\t%{time_total}\t%{time_pretransfer}\t%{http_code}\t%{size_download}\n" "$OPTARG?`date +%s`"
                exit 0
        ;;
 
 
       ?)
                help
        ;;
      default)
                help
        ;;
 
    esac
done

Espero que os sea de utilidad.