La tecnología S.M.A.R.T. permite monitorizar los diferentes parámetros del disco como pueden ser: la velocidad de los platos del disco, sectores defectuosos, errores de calibración, CRC, distancias medias entre el cabezal y el plato, temperatura del disco, etc.

Con este pequeño script pandoraFMS nos avisará si hay algún problema para poder reaccionar a tiempo. Si tienes algún servidor en cierta empresa francesa que empieza por O y acaba en VH deberías de ponerlo si o si. 🙂

El script necesita tener instalada una versión mas o menos moderna de las smartmontools ya que las versiones más antiguas no incluyen el parametro –scan de smartctl

#!/bin/bash
 
OK="PASSED"
 
for i in $(smartctl --scan | awk {'print $1'})
        do
                SMART=$(smartctl -H $i | grep "SMART overall-health self-assessment test result"|tr -d " " |awk '{split($0,a,":");print a[2]}')
                if [ $SMART != $OK ]
                then
                        SALIDA="1"
                        DESCRIBE="ERROR EN DISCO $i"
                else
                        SALIDA="0"
                        DESCRIBE="Check de errores de HD $i con smart"
                fi
                echo "<module>";
                echo "<name>< ![CDATA[Smart $i]]></name>";
                echo "<type>< ![CDATA[generic_data]]></type>";
                echo "<data>< ![CDATA[$SALIDA]]></data>";
                echo "<description>< ![CDATA[$DESCRIBE]]></description>";
                echo "<min_critical>1</min_critical>";
                echo "</module>";
 
        done

PLUS: Si no utilizas PandoraFMS y quieres tener controlada la salud de tus discos este script te enviará un email si S.M.A.R.T. detecta algún problema. Necesitas tener instalado, además del smartmontools, mailutils para poder enviar el email.

#!/bin/bash
OK="PASSED"
for i in $(smartctl --scan | awk {'print $1'})
        do
                SMART=$(smartctl -H $i | grep "SMART overall-health self-assessment test result"|tr -d " " |awk '{split($0,a,":");print a[2]}')
                echo $SMART
                if [ $SMART != $OK ]
                then
                        TO_ADDRESS="correo@micorreoorigen.com"
                        FROM_ADDRESS="correo@micorreodestino.com"
                        SUBJECT="Error en disco smart"
                        BODY=" El disco xxxxx ha dado un error. Revisar cuanto antes"
                        echo ${BODY}| mail -s ${SUBJECT} ${TO_ADDRESS} -- -r ${FROM_ADDRESS}
 
                fi;
 
        done

Mas información sobre S.M.A.R.T:
http://sourceforge.net/apps/trac/smartmontools/wiki
http://lime-technology.com/wiki/index.php/Understanding_SMART_Reports
http://en.wikipedia.org/wiki/S.M.A.R.T

Este sencillo script para pandorafms nos permite comprobar si un raid software tiene algún problema para poder actuar cuanto antes.

#!/bin/bash
for i in $(mdadm --detail --scan | cut -d" " -f2)
        do
                ESTADORAID=$(mdadm --query --detail $i | grep "State :" | tr -d " ")
 
                CHECK=$(echo $ESTADORAID | egrep -c "State:clean,checking|State:active|State:clean")
 
 
                if [ $CHECK -eq 0 ]
                then
                        SALIDA="1"
      #                  DESCRIBE="ERROR EN ARRAY $i"
                        DESCRIBE=$ESTADORAID
                else
                        SALIDA="0"
                        DESCRIBE="Check OK de errores de Raid $i con mdadm"
                fi
                echo "<module>";
                echo "<name>< ![CDATA[Check_raid $i]]></name>";
                echo "<type>< ![CDATA[generic_data]]></type>";
                echo "<data>< ![CDATA[$SALIDA]]></data>";
                echo "<description>< ![CDATA[$DESCRIBE]]></description>";
                echo "<min_critical>1</min_critical>";
                echo "</module>";
 
        done

El script se guarda en la carpeta de plugins del agente de pandora y en la configuración del agente deberíamos añadir la siguiente línea:
module_plugin check_raid

Si queréis comprobarlo a mano se podría utilizar el siguiente comando:

mdadm --detail --scan | cut -d" " -f2 | xargs -I ARG mdadm --query --detail ARG | grep "State :"

Y si no os funcionara mdadm con un simple:

cat /proc/mdstat

Podríais ver el estado del array

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.