Borrar un dominio a mano IspCP
Can’t drop database ‘dbdelsitio‘; database doesn’t exist
[dbdelsitio es un ejemplo]
Ese error surgio cuando estaba haciendo pruebas en un blog con wordpress y borre la DB de forma manual desde el PMA en lugar de hacerlo desde el panel de admin del dominio. Cuando queria borrar el dominio desde el panel me salia “Can’t drop database ‘dbdelsitio‘; database doesn’t exist” dado que el blog que habia creado apuntaba a esa DB (dbdelsitio) y como no la encontraba me salia esa leyenda.
La solución es borrar de forma manual los siguientes registros.
1) /var/www/virtual/dominio_a_borrar
2) /var/cache/bind/db.dominio_a_borrar
3a) Desde PhpMyAdmin y borre las siguiente 2 entradas
3b) Ispcp - sql_database - dominio_a_borrar
3c) Ispcp - dominio - dominio_a_borrar
3d) Ispcp - buscar la db de forma manual en cada 1 de las tablas para borrar los registros. Salvo la tabla logs.
De esta manera se solución el problema y pude borrar el dominio para luego crearlo nuevamente.
Fuente:
Link del post IspCP
Monitoreando los servicios de nuestro servidor (VHCS OMEGA)
Es un sistema proactivo de monitoreo de los servicios que ofrece nuestro servidor, con el podemos hacer que el sistema reactive un servicio parado.
Monit -> http://www.tildeslash.com/monit/
Analizar nuestro correo electrónico utilizando SpamAssassin en postfix (sin amavis) (Nueva Revision)
Este tema ya se trató en el blog, pero me decidí a revisar nuevamente la guía ya que ahora incluyo un script que mueve los mails marcados como SPAM a una carpeta “SPAM” dentro de cada directorio MailDir.
Spamassasin es un filtro semi-inteligente que aplica toda una serie de reglas -de inteligencia artificial- para decidir si un mensaje es o no un mensaje indeseado (SPAM), con propaganda no solicitada.
A continuacion vamos a ver como proteger nuestro sistema postfix con spamassasin.
Analizar nuestro correo electrónico utilizando SpamAssassin en postfix (sin amavis)
Spamassasin es un filtro semi-inteligente que aplica toda una serie de reglas -de inteligencia artificial- para decidir si un mensaje es o no un mensaje indeseado (SPAM), con propaganda no solicitada.
A continuacion vamos a ver como proteger nuestro sistema postfix con spamassasin.
Actualizar el propietario para todos nuestros dominios de nuestro sistema VHCS
Utilizando PHP-CLI (PHP Command Line Interface) programé un pequeño script que conecta a nuestra base de datos mysql de VHCS y obtiene el listado de todos los dominios presentes en el sistema y también a que uid/gid (User ID/Group ID) corresponden en la tabla de usuarios del linux.
Este script puede ser útil para setear el propietario luego de restaurar un backup de todas las cuentas o también para establecer el propietario de los archivos creados con apache/php bajo el usuario propio del servidor, usualmente www-data.
Agregar registros SPF (Sender Policy Framework) a nuestros dominios bajo VHCS
Para verificar si nuestro servidor esta autorizado a enviar correo electrónico en nombre de determinado dominio se crearon los denominados registros SPF que es una verificación a nivel DNS que autoriza a determinados IPs a enviar correo electrónico en nombre del propio dominio. Con esta medida se espera combatir el spam.
Su implementación en el sistema DNS de VHCS es sencilla, basta con editar el archivo /etc/vhcs2/bind/parts/db_e.tpl e insertar lo siguiente en la linea 17:
{DMN_NAME}. IN TXT “v=spf1 a mx ip4:{DMN_IP} ~all”
De tal forma que quede algo mas o menos asi:
{DMN_NAME}. A {DMN_IP}
{DMN_NAME}. IN TXT “v=spf1 a mx ip4:{DMN_IP} ~all”
ns IN A {DMN_IP}
mail IN A {DMN_IP}
www CNAME {DMN_NAME}.
ftp CNAME {DMN_NAME}.
Ahora solo queda decirle a VHCS que regenere los archivos de cada dominio y listo.
Regenerar la configuracion para todos los dominios bajo VHCS
Como bien sabemos cuando agregamos un dominio nuevo a nuestro sistema VHCS el mismo genera los archivos para apache y bind a partir de unas plantillas situadas en su directorio de configuración, ahora bien… si luego de editarlas queremos regenerar dichas configuraciones basta con hacer lo siguiente:
#Detenemos el demonio:
/etc/init.d/vhcs2_daemon stop
#Actualizamos las tablas en MySQL (podemos usar el phpmyadmin tambien, da igual)
mysql -u root -p
***CLAVE_ROOT_MYSQL***
USE vhcs2
UPDATE `domain` SET `domain_status` = ‘change’ WHERE `domain_status` = ‘ok’;
UPDATE `domain_aliasses` SET `alias_status` = ‘change’ WHERE `alias_status` = ‘ok’;
UPDATE `subdomain` SET `subdomain_status` = ‘change’ WHERE `subdomain_status` = ‘ok’;
quit
#Forzamos la actualización manualmente:
/var/www/vhcs2/engine/vhcs2-rqst-mngr
#Iniciamos el demonio nuevamente:
/etc/init.d/vhcs2_daemon start
Activar/Desactivar modulos en Apache 2
En Apache 2, para activar y desactivar módulos, existe un set de comandos muy fáciles de utilizar:
- a2enmod: apache2 enable module, habilita módulos.
- a2dismod: apache2 disable module, deshabilita módulos.
Su uso es sencillo, por ejemplo si queremos habilitar el mod_rewrite en nuestro apache bastara con ejecutar lo siguiente:
#a2enmod rewrite
Por otro lado, si lo que queremos es deshabilitarlo, bastara con ejecutar lo siguiente:
#a2dismod rewrite
Eliminar archivos cuando recibimos el argumento: “Argument list too long”
El otro día me vi en la necesidad de eliminar la cuarentena de mi sistema VHCS (/var/mail/virus) dado que tenia alrededor de 30000 archivos que, decididamente, no quería conservar.
Al intentar eliminarlos directamente con el comando rm recibía un error del tipo: ‘Argument list too long’.
Efectivamente, había muchísimos archivos, así que buscando en internet encontré una linea que me vino de maravillas:
#find . -name ’spam*’ | xargs rm
Con ese pequeño bucle, lo que le decimos es que borre todos los archivos de la ubicación actual (.) que correspondan con el criterio de búsqueda spam*
Utilizar Server Side Includes (SSI) en Apache 2
Server Side Include o SSI es un conjunto de directivas de shtml que nos permiten, entre otras cosas, incluir un archivo dentro de otro.
Antes de que PHP fuese popular se utilizaba mucho para armar paginas en bloques, es decir, si por ejemplo tenemos un menú que repetimos en todo nuestro sitio, podríamos almacenarlo en un archivo llamado menu.shtml y luego incluirlo en todos los demas documentos, así, de esta manera, si tenemos que modificar el menú con solo hacerlo en menu.shtml ya tendríamos reflejado el cambio en todo el sitio.








