Autor: GhOsTi

Publicado el

Cómo chequear, reparar u optimizar tablas o bases de datos MySQL con mysqlcheck

El cliente mysqlcheck comprueba y repara tablas MyISAM. También puede optimizar y analizar tablas.

mysqlcheck es similar a myisamchk, pero funciona de forma distinta. La principal diferencia operacional es que mysqlcheck debe usarse cuando el servidor mysqld está en ejecución, mientras que myisamchk debe usarse cuando no lo está. El beneficio de usar mysqlcheck es que no tiene que parar el servidor para comprobar o reparar las tablas.

mysqlcheck usa los comandos SQL CHECK TABLE, REPAIR TABLE, ANALYZE TABLE, y OPTIMIZE TABLE de forma conveniente para los usuarios. Determina los comandos a usar en función de la operación que quiera realizar, luego envía los comandos al servidor para ejecutarlos.

Hay tres modos generales de invocar mysqlcheck:

shell> mysqlcheck [opciones] nombre_de_base_de_datos [tablas]
shell> mysqlcheck [opciones] –databases DB1 [DB2 DB3…]
shell> mysqlcheck [opciones] –all-databases

Si no nombra ninguna tabla o usa las opciones –databases o –all-databases, se comprueban todas las bases de datos.

mysqlcheck soporta las siguientes opciones:

Continuar leyendo «Cómo chequear, reparar u optimizar tablas o bases de datos MySQL con mysqlcheck»

Publicado el

Maximum Linux Security (2nd Edition) eBook

//i728.photobucket.com/albums/ww281/soft4all/DL4ALL/Maximum-Linux-Security-2ndEdition.jpg
Maximum Linux Security (2nd Edition) eBook

Maximum Linux Security: A Hacker’s Guide to Protecting Your Linux Server and Workstation is designed for system administrators, managers, or Linux users who wish to protect their Linux servers and workstations from unauthorized intrusions and other external threats to their systems’ integrity. Written by an experienced hacker–someone who knows which systems are vulnerable and how crackers get into them–this unique guide to Linux security identifies existing and potential security holes and faults, and then describes how to go about fixing them.

Continuar leyendo «Maximum Linux Security (2nd Edition) eBook»

Publicado el

Solución al error Premature end of script headers al ejecutar CGI en Plesk 9

Este error me ha comido mucho la cabeza¡¡¡¡¡¡¡¡¡¡¡¡¡  la solucíon que yo le he dado al error Premature end of script headers al ejecutar un script CGI en Plesk 9es la siguiente.

Primeramente he restaurado los permisos de usuario del grupo en la carpeta donde se va a ejecutar el cgi, normalmente /var/www/vhosts/midominio.com/cgi-bin/ en Plesk.

chown usuariodeldominio:psaserv cgi-bin/
chown usuariodeldominio:psaserv cgi-bin/*
chown usuariodeldominio:psaserv cgi-bin/test/
chown usuariodeldominio:psaserv cgi-bin/test/test.cgi

nota:  a la carpeta test y al test.cgi le he dado permisos para corroborar que efectivamente rulaba el cgi correctamente y que no era del script que yo intentaba hacer andar.

Por segundo paso le he dado permisos 755 a los scripts y a la carpeta cgi-bin debido que el script cgi que queria hacer andar necesitaba escribir archivos de log dentro de la carpeta.

chmod 755 cgi-bin/*
chmod 755 cgi-bin/test
chmod 755 cgi-bin/test/test.cgi

Y por último he comprobado que la configuración de apache del virtualhost, en plesk normalmente esta en /var/www/vhosts/dominio.com/conf/httpd.include, fijandome que en  la parte ( SuexecUserGroup         usuariodeldominio psaserv )este usuario y grupo sea el correcto y permita la ejecución de scripts cgi en el virtualhost de Plesk, y por su puesto tenga activado el cgi en el virtualhost con la opcion Options -Includes +ExecCGI.

Espero que os haya servidor de ayuda.

Nota el servidor en el que ha salido este error esta sobre Plesk 9.0.1 y Centos 5.2 64bits

Publicado el

URLs estáticas y agradables para cualquier aplicación web

La idea de este artículo es mostrar un sencillo ejemplo de cómo hacer que los links de nuestras aplicaciones web sean “bonitos”, algo así como los que podemos utilizar con WordPress. De tal manera no tendríamos links como estos:

http://www.sitio.com/index.php?accion=consultar&objetivo=personas

Sino algo estéticamente más agradable como:

http://www.sitio.com/personas/

¿Qué necesito?

Es necesario tener en cuenta los prerrequisitos para poder hacer esto. Para este ejemplo voy a suponer que la aplicación la estás haciendo sobre el servidor Apache, y que estás programando en PHP+MySQL. Necesitas:

  • Manejar la mayor parte del trabajo con el archivo index.php. Esto más que un requisito es un consejo. Cuando estés desarrollando aplicaciones en PHP es recomendable que la mayor parte del sistema tenga que ser procesado inicialmente por este archivo, el cual se encargará de manejar todas las peticiones y utilizar los módulos que se necesiten. Esto, por supuesto, NO quiere decir que TODO el código vaya dentro del archivo index.php; una buena práctica es separar el código en módulos y llamarlos con funciones como include o require.
  • Es necesario tener instalado el mod_rewrite, el cual se utilizará desde un archivo .htaccess. El ModRewrite es un módulo para Apache que por lo general se configura (definir reglas) en el archivo httpd.conf, pero es posible poner una configuración ModRewrite en cualquier directorio de nuestro servidor web dentro del archivo .htaccess.
  • Puesto que de acuerdo al string que pasemos en la URL se debe determinar qué hacer, es necesario hacer algo de esto:
    • Hacer que dentro de la base de datos la llave primaria de la tabla a consultar sea una cadena de texto, ó
    • Hacer otro campo en la tabla de MySQL aparte de la llave primaria

Ejemplo

Para nuestro ejemplo necesitamos un servidor Apache con ModRewrite, PHP y MySQL. Lo primero es crear la base de datos, así:

Continuar leyendo «URLs estáticas y agradables para cualquier aplicación web»

Publicado el

Evitar el SPAM en Plesk 9

Plesk 9, al igual que sus antecesores tiene un pequeño problema de spam. Si no esta bien configurado, el servidor puede ser usado facilmente para mandar spam, el problema viene en la configuración de qmail, si echamos un vistazo a la “whitelist” vemos que tiene configurado el host 127.0.0.0/32, lo cual, hablando claramente, significa que autoriza a cualquier IP a mandar correo a traves de su servidor SMTP… un verdadero problema.

Lo primero que debemos hacer es borrar esta entrada e incluir 127.0.0.1/8, con lo cual limitamos en envio a la ip local.

El problema de hacer esto es que automaticamente hemos desautorizado a que cualquier script dentro de nuestro server envie correo, incluyendo la funcion sendmail() o los correos de wordpress para autorizar usuarios, etc,etc

La solucion es sencilla, añadir una nueva entrada en la whitelist para cada ip configurada en nuestro servidor, del tipo x.x.x.x/8. Ya tenemos el problema casi solucionado

Ahora configuramos la proteccion de spam en blacklisk DNS, es decir, la proteccion DNSBL, añadiendo estas dos zonas, separadas por punto y coma, ta como estan aqui

  • sbl.spamhaus.org;cbl.abuseat.org

Entramos por SSH en nuestro servidor y reiniciamos qmail con

  • /etc/init.d/qmail restart

Y listo…