martes, 29 de mayo de 2012

Mirroring entre hosts y discos. Parte 1: Claves públicas y privadas en ssh

Debido a las necesidades de la web de la empresa, contratamos una solución de servidor dedicado con dos máquinas en tamden. La idea principal es que estas máquinas realicen un balanceo de carga entre ellas para que la web de la empresa, el cual es el principal servicio que soporta, agilice su rendimiento de forma considerable.
Para realizar esto vamos a configurar el mirroring cruzado, y lo primero que haremos es conseguir comunicación vía ssh.

Ssh permite una forma de comunicación mediante claves públicas y privadas. El funcionamiento es sencillo: se generan 2 claves, una pública y una privada en el server1. Luego se le pasa la clave pública al server2 haciendo que server1 este autorizado a acceder vía ssh sin necesidad de poner la clave.

Veamos como podemos realizar este proceso:
Lo primero que hay que hacer es generar las claves en el server1 con el siguiente comando:
# ssh-keygen -t rsa

En el directorio .ssh de nuestro home (en este caso /root) se creará la clave privada (id_rsa) y la pública (id_rsa.pub).
Ssh-keygen nos pedirá una frase de paso. La dejaremos en blanco para que no nos la pida al conectarnos al equipo remoto. 
Tras esto podemos hacer un ls del direcorio /root/.ssh/ y tendremos algo parecido a esto:
Salida ls





Ahora pasamos a poner el contenido del fichero id_rsa.pub en el fichero authorized_keys del server2.
Para realizar este proceso hay dos forma: copia vía scp el fichero id_rsa.pub del server1 y luego añadir su contenido al fichero authorized_keys del server2; o bien usar el siguiente comando que realiza el proceso de pasar la clave pública de forma automática:
# ssh-copy-id -i /root/.ssh/id_rsa.pub root@server2
Tras esto podemos hacer un cat del fichero /root/.ssh/authorized_keys del server2 y tendremos la siguiente salida:
Salida cat

Ahora solo hay que realizar el proceso inverso en el server2 y ya podremos acceder a ambos servidores con root sin que nos pida contraseña. Saludos curiosos.

jueves, 24 de mayo de 2012

Técnicas de SEO parte 1: Black Hat

Tras la remodelación que estamos realizando de nuestra página web de hostales. Nos ha surgido el problema del posicionamiento.
Al ser una web que se dedica a la venta hotelera nos conviene el tener una cantidad elevada de vistas, para así tener el máximo número de reservas.
Y aquí llegamos a la parte de SEO (Search Engine Optimization), que no es más que las técnicas necesarias para la optimización de búsqueda para el posicionamiento en buscadores. Para entendernos: realizar los cambios necesarios para que nuestra web aparezca en las primeras posiciones en los buscadores.

Para poder realizar esto hay dos técnicas: las legales y las ilegales.
En esta primera parte vamos a ver las ilegales llamadas técnicas black hat.
Antes de mostrar estas técnicas decir que son completamente ilegales y que uso puede provocar que los principales buscadores os etiqueten en sus listas negras y seáis penalizados.

Veamos cuáles son:
  • Cloaking: está técnica de black hat implica mostrar al bot del buscador una página web distinta a la que ven los visitantes. Se realiza insertando un texto optimizado con palabras clave específicas para los buscadores. Hace algún tiempo se mencionaba en ciertos foros de Internet como algunos lo había conseguido mediante una web en texto plano que redirigía a una web en flash; ya que el flash no lo pueden leer los bots, la web que redireccionaba provocaba  una alto índice de pagerank y por tanto se encontraba en las primeras posiciones de los buscadores de forma inmediata.
  • Texto invisible: Se realiza colocando texto en la web del mismo color que el fondo de la página. Esto tiene como fin que el bot del buscador lea el texto pero este no pueda ser leído por el usuario que visita la web.
  • SPAM en foros: Se trata de visitar distintos foros, comentando en ellos y añadiendo al final de cada comentario la url de nuestra web. Aunque esta técnica es la menos ilegal de todas, es cierto que en algunos foros en los que los admin detecten que estías haciendo spam para dejar links podrían informar de ello a cierto sitios de Webmaster (generalment el de google) y os podrían llegar a penalizar, aunque yo aun no he escuchado nada parecido.
  • SPAM de keywords: a Google le gusta que las palabras clave se encuentren, de manera natural, en el texto escrito. Si ponemos en un texto: “Mi Hotel es el mejor Hotel que podemos encontrar en los sitios de Hoteles y es un Hotel ideal para pasar unas vacaciones en un Hotel”… no sólo es redundante, sino que estás rompiendo la regla del 3 por cierto (3 palabras clave cada 100 palabras).
Estas técnicas provocaran un aumento en el posicionamiento de la web pero solo hasta que os pillen, que con la tecnología de los bots de los bucadores actuales será en un muy corto espacio de tiempo.
Pero claro, como nosotros somo buenos, hemos optimizado nuestra web con técnicas SEO White Black, pero eso para otra entrada. Saludos curiosos.

jueves, 10 de mayo de 2012

Error con acentos y ñ en la Web

No se si os habrá pasado, pero no hay nada más poco etético que cuando estás visitando una web, no aparezcan los acentos ni las ñ sino que en su lugar tenemos el odioso símbolo de �.

Bueno pues para daros una alegría a los webmasters y los administradores de sistemas: se puede arreglar (como casi todo en la vida).

Es algo sencillo, lo único que tenemos que hacer es descomentar la línea siguiente en el apache.conf del servidor web:

AddDefaultCharset ISO-8859-1

Con esto le decimos al servidor que identifique los caracteres antes mencionados. Saludos curiosos.

miércoles, 9 de mayo de 2012

Cómo migrar una web de forma correcta

Hoy tras superar numerosos obstáculos para completar la migración del servidor web... a vuelto a estar operativo de nuevo.

Paso a mencionar cuáles son los pasos a realizar en caso de que se quiera hacer una migración de un servidor a otro en 4 partes:
  1. Copiamos todo el contenido del servidor antiguo al nuevo.
  2. Cambiamos los registros DNS para nuestro dominio y los apuntamos al nuevo server. Esto tarde de 36-48 en realizarse, puesto que los DNS de Internet han de actualizarse y propagar la nueva dirección del domino.
  3. Configuramos un servidor MySQL duplicado para que la base de datos del servidor antiguo y el nuevo se mantuvieran actualizadas.
  4. Cuando ya está movido todo y los DNS apuntando al nuevo server, tenemos que dar de baja los virtual host de apache para la web antigua. Con ello ya nadie accederá por equivocación a la antigua web.
  5. Quitamos el servidor mysql duplicado.
  6. Resolvemos errores si los hay.

En primer lugar cabe mencionar que nosotros migramos la web corporativa haciendo una copia con rsync del servidor completo. Esto tiene algunas ventajas y algunos inconvenientes.
  • Las ventajas son que al copiar todo, no tenemos que preocuparnos por volver a instalar todos los servidores que teníamos anteriormente y no hace falta migrar los usuarios ni los ficheros de configuración.
  • Los inconvenientes es que hay que cambiar de forma manual multitud de ficheros que tienen parámetros que hacen referencia al servidor antiguo. Como ejemplos tenemos el /etc/hosts, /etc/hostname, archivos .php de la web, configuración de los servidores, etc...
 La diferencia radica que montando todo desde 0 sabes que es lo que estás configurando aunque tardas más tiempo en volver a tener toda la infraestructura y al copiarlo tardas mucho menos tiempo pero entras en "pánico" en caso de que te aparezca algún error.

Este fue el caso nuestro: el correo dejó de funcionar y la parte de la web que administraba las reservas no funcionaba.

Analicemos por partes que es lo que ocurría y que soluciones tomamos para remediarlo.

En primer lugar y mayor problema de todos era que el servidor web no estaba recibiendo correo. El 80% de las reservas que los usuarios realizaban para nuestros establecimientos se recibían por correo. Esto se tradujo en 3 días sin tener reservas, hablando en plata 3 días perdiendo dinero.
  • Creamos una entrada mx en el servidor DNS con el nombre mail.hostalescomohoteles.com.
  • Cambiamos la configuración de postfix para que entendiera que el nombre del nuevo servidor y la dirección ip habían cambiado.
  • Configuramos Clamav (antivirus para el correo) para que trabajara con el nuevo nombre del servidor.
  • Configuramos SpamAssasin (configuración antispan) para que trabajara con el nuevo nombre del servidor.
  • Descongestionamos la cola del correo del servidor para los mensajes acumulados.
 En segundo lugar la web dejó de funcionar en su totalidad.
  • Cambiamos las direcciones de los virtual host de apache, debido a que están apuntando al servidor antiguo.
  • La parte de administración de reservas no funcionaba por lo que hay que dar de alta una entrada A en el servidor DNS para secure.hostalescomohoteles.com. Esta dirección gestiona la parte de las reservas con seguridad SSL. (Puerto 443)
  • Ahora nos arroja un error a la hora de aceptar los pagos, esto era debido por que en multitud de archivos de la web estaba puesto la dirección ip del servidor antiguo. En este caso en especial era cuando realizábamos el pago a través del sistema tpv, porque enviaba la información al servidor antiguo y no al nuevo.
Tras solucionar estos resquicios ya tenemos el server funcionado. Saludos curiosos.

jueves, 3 de mayo de 2012

Error Mysql "Checking for corrupt, not cleanly closed and upgrade needing tables"

En otro de los capítulos de la migración del servidor web de la empresa, hemos tenido un gran problema a la hora de migrar la base de datos.

De repente el servidor de mysql dejo de funcionar. Al ver que es lo que ocurría vimos que no se iniciaba el servicio. Fallaba.

El problema parecía que el sistema de mysql se había corrompido con el cambio de servidor, cosa que no entendemos porque ha ocurrido.

Sin más, la solución era aparentemente sencilla: reinstalar el pequte de mysql-server. Pero, y he aquí lo que nos ocupa, ahora al iniciar el servicio nos provocaba el siguiente error:
hostalescomohoteles:~# /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..





La razón por la que nos arroja este error la comprobamos en el syslog del sistema:

May  3 10:02:12 hostalescomohoteles mysqld[14950]: 120503 10:02:12 [Note] Retrying repair of: './hosteltouristworld_com/registros_ip' with keycache

Lo que nos indica es que la tabla registros_ip de la base de datos hosteltouristworld_com esta corrupta. Por lo que pasamos a repararla con el siguiente comando de la shell:
myisamchk -r --safe-recover /var/lib/mysql/hosteltouristworld_com/registros_ip.MYI

Esto recupera los registros de la tabla que se hallen corruptos, y devuelve el servidor al estado óptimo de inicio.

También se podría dar el caso de que la tabla corrupta sea una de las tabla del sistema, por lo que la forma de solucionarlo sería mucho más delicada. Para recuperar este tipo de tablas podéis consultar este artículo, que ofrece información detellada sobre los pasos a seguir. Saludos curiosos.

Install Drupal 8 in CentOS

Drupal is an open source, flexible, highly scalable and secure Content Management System (CMS) which allows users to easily build and create...