Habitualmente hay problemas con las colas de correos; correos que se quedan atascados, o usuarios que mandan lo que no deben.

Para borrar todos los correos de un usuario en Plesk no conozco ninguna herramienta, de modo que he hecho esta pequeña instrucción:

/usr/local/psa/admin/bin/mailqueuemng  `/var/qmail/bin/qmail-qread | grep CORREO |  awk '{print $6}' | awk 'gsub("#","-d")' | tr "\n" " "`

No hay que olvidar sustituir “CORREO” por el correo que queramos borrar, o el dominio!

Espero que sea util !


En el caso del SPAM, la mejor defensa, es una buena defensa, pero en Plesk, esto a veces es complicado porque carece de las herramientas y potencia necesaria para hacerlo. En este punto creo que cPanel está mucho más avanzado, pero si hemos elegido Plesk,posiblemente ya sea tarde para cambiar de dirección.

Comenzamos por diagnosticar problemas en el envío de spam. Lo habitual es recibir quejas de usuarios porque no les llegan correos, o porque los correos que ellos envían no llegan a sus destinatarios. Esto no es debido a un fallo, es debido a que las colas de correo tienen tanta carga por procesar, que cada correo que se envía tarda horas en salir o llegar a destinatario.

Para evitar que sea el usuario quien informe del error, se debería poner algún sistema de aviso temprano, pero ya hablaré de esto en otro post.

Para localizar estos errores, Plesk cuenta con una herramienta para gestionar las colas bastante interesante, pero cuando la cola es de 100.000 correos, no funciona nada bien; se cuelga y no ejecuta las ordenes, de modo que no queda otra opción que comprobar las queus desde la consola:

[root@servidor ~]# /var/qmail/bin/qmail-qstat

Lo que debería devolver algo similar a esto:

[root@servidor ~]# /var/qmail/bin/qmail-qstat
messages in queue: 16784
messages in queue but not yet preprocessed: 14512 

Casi sin duda se trata de un envío de spam.

Hay varias causas para que esto ocurra, pero las más probables son:

  • Cuenta de correo de un cliente comprometida
  • Script php o cgi comprometido
  • Rootkit o similar instalado a través de una vulnerabilidad del sistema.

Vamos a describir cómo detectar de donde vienen los correos:

Continue reading


Desde que Plesk actualizó su base de datos en Plesk 10 y guardó las contraseñas de FTP y correo cifradas, el acceso al SQL no ha resultado útil para poder ver las contraseñas, sin embargo, Plesk integra una herramienta para poder verlas desde la consola.

Solo hay que conectar a la consola usando un terminal si utilizáis linux o mac, y putty.exe si utilizáis windows.

Para el que no se acuerde, el usuario para loguear es “root”, y la contraseña es la misma de “admin” en el panel Plesk. Una vez en la consola solo hay que ejecutar lo siguiente:

/usr/local/psa/admin/sbin/mail_auth_view

Plesk en ese momento mostrará una lista de todos los correos en el servidor.

Continue reading


Para compltar esta serie de posts sobre telemetría y data logging con arduino, queda unicamente la parte de guardar datos en algún dispositivo local para poder ejecutar más tarde un post proceso. Para esto he elegido una tarjeta SD con la cual se puede hablar a través del protocolo SPI. Para esto compré un lector de tarjetas muy económico de de el fabricante Waveshare. Buscando SD reader waveshare se puede encontrar el pequeño interfaz en ebay, dealextreme etc. Utilicé este por el precio super económico ya que todos leen exactamente igual.

El lector tiene los pines identificados por las dos caras de la placa, para nosotros con arduino las interesan los nombres del reverso de la placa (la parte que lleva el logo de waveshare).
Conectarla arduino es muy facil, solo tenemos que utilizar los pines del bus SPI, en el arduino UNO, leonado, etc, estos son:

MOSI – pin 11
MISO – pin 12
CLK – pin 13
CS – pin 4 (se puede seleccionar otro pin sin problema, no forma parte del SPI)

Sin embargo en arduino MEGA, que es la placa que yo uso para este sketch, los pines son:

MOSI – pin 51
MISO – pin 50
CLK – pin 52
CS – pin 4 (se puede seleccionar otro pin sin problema, no forma parte del SPI)

Para la correcta lectura es necesario poner resistencias los cables MISO, MISI y CS, pero a mi me ha pasado con dos tarjetas distintas que el valor de estas resistencias no servía para ambas, con lo que estos valores que indico son orientativos, y haciendo pruebas debería funcionar en unos minutos:

MOSI – 1k
MOSO – 1K
CS – pull up 10k (resistencia linea de 3.3V)

¡¡ Además de esto hay que darse cuenta de que la placa debe ser alimentada con 3.3V !!

Después de cablear correctamente podemos utilizar los sketckes de test que incluye el IDE de arduino:

Comprobar comunicación con tarjeta:

Continue reading


Para la comunicación entre dispositivos existen diferentes posibilidades como puerto serie, spi, i2c, y muchas más, pero estas tres formas las lleva implementadas arduino. Lo más normal es utilizar el puerto serie ya que es el que todos dominamos pero por vaguería acabamos por no implementar control de errores, y puesto que el stack de i2c lo controla y está disponible, no hay razón para no usarlo.

I2c es un protocolo diseñado por phillips la cual, y se puede usar sin ningún tipo de problema legal puesto que la patente ya ha expirado. Este protocolo se ejecuta sobre tres cables, un cable base (GND), un cable con señal de reloj (SCL) y un tercero con datos (SDA). Todos ellos se conectan en paralelo.
En este protocolo está contemplado la existencia de un dipositivo master, que inicia la comunicación, y dispositovos esclavos. Es posible que exista más de un master, pero no al mismo tiempo, es necesario detectar si el canal está libre para poder hacer cambio de master. En arduino no he necesitado hacerlo ya que con un solo master se cumplen mis necesidades, pero es importante tener en cuenta que solo el master inicia comunicación, tratandose el slave como un objeto al que se instancia, pero este nunca inicia un flujo.

He realizado dos tipos de pruebas; arduino como master, y dispositivo como slave, y en otro escenario, dos arduinos, uno como master y otro como slave. Para realizar estos dos sketches, necesitamos la librería WIRE, que lleva programado todo el protocolo i2c.

En el escenario 1 he utilizado como master un arduino mega, y como slave un dispositivo acelerometro ADXL345 (Aquí teneis su datasheet) En este documento se puede ver que el dispositivo tiene asignado por defecto el numero 0×53 como identificador con el cual debemos dirigirnos a él.

En el caso del arduino mega los pines SDA y SCL están ubicados en los pines 20 y 21 de la placa, son lo que hay que cablearlos hasta los pines SDA Y SDL del acelerómetro, y alimentar con 3.3v así como conectar GND.

Para evitar cableados erroneos, y puesto que tenía una placa de prototipado, soldé lo que interesaba en ella; una radio RF, un GPS y el aceletrómetro.

Una vez cableado esto, podremos cargar este código en arduino para comprobar el acelerómetro:

Continue reading