malditohosting La bitacora del hosting

o en cualquier otro, claro... esto viene siendo muy necesario cuando te cansas de que a tus clientes le suban porqueria en php con sus programaciones precocinadas (oscommerce? :P), de esta manera, si le suben un php que envia porqueria, una webshell o cualquier malware, evitaremos que se pueda ejecutar.
Existen varias formas de hacerlo (htaccess, vhost.conf...) pero lo mas facil, bonito y elegante, es meter un fichero .conf (con el nombre que querais.... mifichero.conf) dentro del directorio conf.d de nuestro servidor apache.
Ruta para debian:

/etc/apache2/conf.d

Ruta para centos/redhat/fedora/similares:

/etc/httpd/conf.d

contenido del fichero:

< LocationMatch "/images/.*\.(php3?|phtml)$">
Order Deny,Allow
Deny from All
< /LocationMatch>

Luego, con un poco mas de imaginacion, se pueden agregar mas cosas... por aqui, de momento, tambien agregamos:

< LocationMatch "backuptoster\.php">
Order Deny,Allow
Deny from All
< /LocationMatch>

al lanzar el servicio de courier-imap nos encontramos con esto:

Starting Courier-IMAP server:
Starting imapd/usr/lib/courier-imap/imapd.rc: xrealloc: ../bash/subst.c:514: cannot reallocate 1024 bytes (0 bytes allocated)
failed
Starting imap-ssl/usr/lib/courier-imap/imapd-ssl.rc: xmalloc: ../bash/braces.c:136: cannot allocate 511 bytes (0 bytes allocated)
failed

en mi caso, con debian... no se si con redhat/centos/fedora pasara lo mismo -con Ubuntu seguro que si-.
La ñapa del momento es editar el fichero imapd (usualmente /etc/courier-imap/imapd) y modificar IMAP_ULIMITD=65536
por IMAP_ULIMITD=131072

esa firma tan molesta que mete por defecto atmail en todos los mensajes, y que seguro que a muchos clientes no les hace ni un poquito de gracia, se elimina de una forma muy muy sencilla.

Para servidores linux:

editamos el fichero /var/www/atmail/libs/Atmail/Config.php
buscamos: 'footer_msg' => 'Msg sent via @Mail - http://atmail.com/',
y cambiamos lo que va entre las comillas simples por lo que nos de la gana (o lo dejamos vacio)

Para windows el fichero esta en:

C:\Inetpub\vhosts\webmail\atmail\libs\Atmailconfig.php

una vez hecho esto, relanzais el servicio web y a correr.

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.