malditohosting La bitacora del hosting

De vez en cuando, da un poco de guerra no parar de recibir avisos de drweb, de que si cierto mail tenia virus, que se ha eliminado, etc.. al final, y en determinados escenarios, llega a ser peor que el spam.
Para cargarnoslas, no tenemos mas que editar el fichero /etc/drweb/drweb_qmail.conf y dejar el apartado "VirusNotification" asi:

[VirusNotifications]
SenderNotify = no
AdminNotify = no
RcptsNotify =no

Tras cambiarlo, relanzamos drweb:

# service drwebd restart

y listo, no deberiais recibir ni una mas.

Engorroso error que nos podremos encontrar en el maillog de nuestros servidores linux con plesk 9.3:
"Unable to get 'From:' string from SMTP session"

Esto se ha solucionado en versiones posteriores, pero no nos hara falta actualizar deprisa y corriendo, tenemos un parche en:

http://download1.sw-soft.com/Plesk/Hotfix/PleskUnix/9.3.0/32111/update.tar.bz2

Para instalarlo y ponerlo a funcionar, la receta:

wget http://download1.sw-soft.com/Plesk/H...update.tar.bz2 # bajamos
tar jxvf update.tar.bz2 # descomprimimos
/etc/init.d/qmail stop # paramos qmail
cp -p /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-queue.BACKUP # hacemos una de esas copias de seguridad por si rompemos algo

y ahora, dentro del directorio "update" vemos:

venga.. otro post, pero que nadie piense que por ello estare mas activo de nuevo.
Hoy me encontre con este error:

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

al pasar un hdparm.. y se me pusieron de corbata. Al final, una tonteria (je..). Por lo visto, mi querida centos, tenia un hdparm bastante viejo: hdparm-6.6-2 y con solo actualizar la version, se me acabaron los problemas. Pongamos por ejemplo, la 9.9:

hdparm-9.9]# history|tail
878 wget http://downloads.sourceforge.net/project/hdparm/hdparm/hdparm-9.9.tar.gz
879 tar xfvz hdparm-9.9.tar.gz
880 cd hdparm-9.9
881 make
882 ls
883 ./hdparm -tT /dev/mapper/VolGroup00-LogVol00

listo, un hdparm que funciona como deberia

pd: si, me era mas comodo copiar el final del history.

pues eso.. al principio empece con tiempo y ganas todo esto, pero ahora mismo no dispongo de todo el tiempo que me gustaria para repasarlo, tengo muchisimo trabajo y demasiadas "cosas que hacer". Hay un comentario muy de cuando en cuando.. y hoy me he dado cuenta que tenia, sin leer, uno de julio. Dificilmente ire añadiendo actualizaciones o ire respondiendo cosas -lo que no quita que, si alguien pregunta algo, otro visitante le pueda contestar.. que estamos en la era 2.0-. No voy a cerrar la web, porque me parece un pequeño kb que puede venir bien (me viene bien hasta a mi, asi que no, no la cierro), pero tampoco le voy a hacer demasiado caso.

y por mas que le grites... tu subes algo por ftp y te dice:

Lost data connection to remote host: Broken pipe.
552: Transfer aborted. Disk quota exceeded

Si tu limite de quota es superior a lo que estas ocupando, es posible que tengas que pasar un quotacheck. Hoy me estaba pasando con uno que ocupaba poco mas de 1mb y su quota era de 50mb. El proceso es sencillo, pero hay que saber lo que se esta haciendo.

Comenzamos la receta: tenemos que saber como se llama el disco sobre el cual estan los datos (hda1, hdb1, sda1, etc..) en nuestro ejemplo, sera /dev/sda1. Esto lo podeis ver con un df o un fdisk -l, por ejemplo.

Deshabilitamos las quotas:

[root@malditoserver root]# quotaoff /dev/sda1
[root@malditoserver root]#

Ejecutamos el check

[root@malditoserver root]# quotacheck -m /dev/sda1
[root@malditoserver root]#

Habilitamos de nuevo

[root@malditoserver root]# quotaon /dev/sda1
[root@malditoserver root]#

buen provecho.

mas de dos vueltas le he tenido que dar a soberana tonteria. Un cliente habia creado un fichero en windows que terminaba en un punto, algo asi como "mi fichero." sin .txt o .doc o .tuextensionfavorita. El problema es que, al darle a renombrar desde el explorer, nos decia algo asi como "cannot read from the source file or disk" y, desde una consola, The system cannot find the file specified. Vamos, que no lo veia ni pa'tras. Despues de probar a borrarlo en formato 8.3 (si, que somos todos muy habiles, haciendo un dir /x) y complicarme la vida un poco, he visto que era tan "facil" como renombrarlo asi:
C:\>ren "\\?\C:\directorio\donde\estaba\fichero maldito." nuevonombre.txt
Y ya esta, ahora si que sabe donde esta :-)

bueno, vale para drweb.. como seguramente valga para antispam y demas. Solo hay que dar dos pasos:

-Cambiamos el valor en la base de datos psa. Para hacerlo en todos los buzones, nos logeamos como admin en mysql:

mysql -uadmin -p`cat /etc/psa/.psa.shadow`

(tambien vale mysql -uadmin -p y, al entrar, le damos la clave del panel plesk)

una vez en mysql, nos aparecera una consola:

mysql>

en la que ponemos:

mysql> use psa

nos dira algo como:

Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

y añadimos:

mysql> update mail set virusfilter = 'any';

nos deberia devolver:

Query OK, 76 rows affected (0.02 sec)
Rows matched: 76 Changed: 76 Warnings: 0

Cuando en plesk, a la hora de modificar un usuario, crear una bd o realizar cualquier tarea con postgre, nos dice algo asi:

FATAL: 54000: la base de datos no está aceptando comandos para evitar pérdida de datos debido al problema del reciclaje de transacciones en la base <>
HINT: Pare el proceso postmaster y utilice una conexión aislada para limpiar (vacuum) la base <>
LOCATION: GetNewTransactionId, varsup.c:72

es que, ademas de ser unos vagos (ese mantenimiento habitual...!) tenemos un problema. Toca parar el servicio de postgre y ejecutar vacuum con una conexion stand-alone. Para ello, empezamos parando el postgre:

# /etc/init.d/postgresql stop

Una vez parado, nos ponemos con el usuario postgres

# su - postgres

Y, una vez ahi, abrimos la "conexion aislada" que nos decia plesk:

# postgres postgres

En este caso, la hemos abierto para la bd "postgres". Si se quejase de la bd "manolo", pues seria asi:

# postgres manolo

esta ya me ha pasado 2 o 3 veces, y al no ser muy habitual, siempre se me olvida, asi que..
cuando os aparece esto al enviar, es porque vuestro amigo el drweb os ha declarado la guerra. Para solucionarlo, hay que empezar por matarle:

#rpm -e drweb drweb-qmail

una vez desinstalado, tendreis que volver a meterlo. Si teneis los paquetes bajados en el /root/psa o similar, podeis instalarlos con rpm -Uvh (quiza necesiteis un --force), pero si no, lo mas comodo es acceder al panel e ir al actualizador/updater, dentro de servidor/server. Buscamos el drweb, lo instalamos, esperamos a que nos mande un mail diciendo que ya esta y, por si acaso, entramos de nuevo por ssh y ponemos:

#service drwebd status

a ver si esta en ejecucion. Si lo esta, todo tiene que funcionar :-)

intentamos hacer un backup, desde el propio plesk, y nos devuelve esto:

Unable to create backup session: Specified file is not accessible

He visto por ahi teorias sobre el espacio en el tmp (en el foro de swsoft) y demas, pero, en realidad, es tan facil como:

chown -R psaadm:psaadm /var/lib/psa/dumps

ejecutamos eso, por ssh, y a correr.

para los sufridores del spam. Entramos por ssh y ponemos:

echo "#" > /var/qmail/control/doublebounceto

una vez hecho esto, relanzamos qmail

service qmail restart o /etc/init.d/qmail restart

cuando teneis mas de una version de asp.net instaladas (o añadis alguna) y plesk no os muestra, dentro de la opcion "configurar", la version a utilizar para el sitio y se emperra en utilizar una sola, se corrige muy facil con defpackagemng. Nos vamos a una consola y, dentro del directorio "admin/bin" de plesk, que suele ser:

c:\program files\swsoft\plesk\admin\bin

ponemos:

defpackagemng.exe --fix

y a probar.

Por fin algo que merece la pena ser posteado.. (vaya excusa para estar meses sin escribir) He visto, en pleskwindows, al ir a cambiar contraseñas, activar frontpage, etc.. cualquier cosa que hagais dentro de "configurar", cuando el nombre del dominio es algo largo, nos encontramos con un serror como este:

Error: Unable to update hosting preferences:
The following system user attributes were not changed:
login (Unable to lookup SID for name newusername: (1332) No mapping between account names and security IDs was done.)
quota (Unable to lookup SID for name newusername: (1332) No mapping between account names and security IDs was done.)

Bueno, en realidad, primero dice que el usuario ya existe.. y todos, que somos muy listos, le cambiamos el nombre.. y nos da ese error.

Despues de googlear, he visto que la gente preguntaba incluso en el foro de swsoft, pero no tenian respuesta. Asi que.. tocaba trastear (al fin! una excusa..)

La razon, es que tiene el usuario mal en algunos sitios.. porque, al ser tan largo, el usuario en si, entra.. pero cuando le añades IUSR_ delante, no. La solucion es:

Hoy vamos a comentar un par de utilidades que, no siendo la panacea, de cuando en cuando estan bien, y nos pueden echar una mano a la hora de detectar algunas intrusiones. Estas son chkrootkit y rkhunter.

RKHUNTER:

Descargar de: http://sourceforge.net/projects/rkhunter/

cd /usr/src
wget http://puzzle.dl.sourceforge.net/sourceforge/rkhunter/rkhunter-1.2.9.tar.gz
tar zxvf rkhunter-1.2.9.tar.gz
sh /usr/src/rkhunter-1.2.9/installer.sh
/usr/local/bin/rkhunter --update

CHKROOTKIT:

Podeis descargarlo de:

http://freshmeat.net/projects/chkrootkit/

Pasad primero por esa web, por si el enlace a la ultima version hubiese cambiado y:

cd /opt
wget http://freshmeat.net/redir/chkrootkit/20715/url_tgz/chkrootkit.tar.gz
tar xfvz chkrootkit.tar.gz
cd chkrootkit-0.47/
./chkrootkit