Estoy buscando a alguna persona que quiera desarrollar conjuntamente la web www.blogeen.com. Esta persona debe disponer de conocimientos de LAMP. Podéis acceder a la web en www.blogeen.com, usuario: blogeen password: blogeen.
Podéis descargaros un PDF con las funcionalidades de Blogeen haciendo click aquí
Click here to translate this post
Si necesitáis ejecutar un window.open programado (sin que el usuario haga click), os encontraréis con que IE y FF bloquean este pop-up. Para evitar este problema podéis utilizar el siguiente código:
function openWindow()
{
window.open (”http://www.google.com“,”owindow”,”scrollbar=0,statusbar=0, menubar=0,resizable=0,width=400,height=300″);
}
// Para FF
function clickElement (element) {
var evt = element.ownerDocument.createEvent(”MouseEvents”);
evt.initMouseEvent(’click’, true, true, element.ownerDocument.defaultView, 1, 0, 0, 0, 0, false, false, false, false, 0, null );
element.dispatchEvent(evt);
}
// Si es un navegador IE
<body onload=”document.links[0].click();”>
// Si es un navegador FF
<body onload=”clickElement(document.links[0]);”>
<a href=”#” onClick=”openWindow();”></a>
Click here to translate this post
Si en algún momento necesitáis (en Windows) enviar una secuencia de comandos, bajaros este program TST10-Telnet Client
Imaginemos que necesitamos conectarnos automáticamente a un servidor de telnet sin tener que teclear el usuario y password. Con el cliente telnet que Windows nos proporciona no se puede realizar un login automático. Con el cliente TST10 sí podemos conseguirlo, tan sólo se debe crear un TXT llamado script.txt con el siguiente contenido:
localhost
WAIT “Username:”
SEND “usuario\m”
WAIT “Password:”
SEND “password\m”
WAIT “>”
WAIT es el texto que el servidor nos envía. Si vuestro servidor contesta Usuario: en vez de Username: deberéis cambiarlo. Se puede crear un script utilizando todas las funciones que el servidor FTP dispone.
Para ejecutarlo en la línea de comandos introducimos:
TST10.exe /r:script.txt
Click here to translate this post
Si vuestro presupuesto no os permite gastaros miles de € en una solución de balanceo de servidores mediante hardware, podéis estar tranquilos ya que existen numerosas aplicaciones gratuitas que ofrecen el mismo resultado.
A un nivel muy sencillo tenemos Perlbal (http://www.danga.com/perlbal). Se trata de una sencilla aplicación escrita en Perl para el balanceo de servidores HTTP. Se puede n agregar y eliminar servidores sin la necesidad de parar el servicio. Perbal permite monitorizar el servicio mediante su aplicación de consola.
En un nivel intermedio tenemos Pound (http://www.apsis.ch/pound), también gratuita. Pound balancea las peticiones entre los servidores disponibles, detecta sercidores fallidos y permite conexiones “Sticky”. Es una aplicación bastante completa, pero falla al no ofrecer un sistema de monitorización. En ningún momento se puede ver cuantas conexiones dispone cada servidores, cuales de esos servidores están en línea, etc.
Linux Virtual Server (http://www.linuxvirtualserver.org) es el paquete de software de balanceo de servidores más completo que existe. Require mucho más tiempo para configurarlo, pero una vez montado funciona de maravilla. Si el servidor tiene una versión de kernel inferior a la 2.6 LVS require que el kernel sea parcheado. Si la versión del kernel es =>2.6 entonces LVS viene incorporado en el propio kernel. LVS permite redireccionar el tráfico mediante NAT o IP tunneling. NAT mueve el tráfico desde el servidor balanceador al servidor final y devuelve el contenido de respuesta de vuelta al cliente pasando por el servidor balanceador. IP tunneling mueve el tráfico del servidor balanceador al servidor final, pero a diferencia de NAT, la respuesta es enviada directamente al cliente sin necesidad de pasar por el servidor balanceador. LVS ofrece una gran cantidad de estadísticas sobre el servicio.
En el siguiente tutorial mostraré paso a paso, como configurar un servidor de balanceo (Director) con 2 servidores finales (Real Servers).
Click here to translate this post
SLURM es una utilidad que permite controlar el tráfico entrante y saliente que genera tu servidor.
Lo puedes descargar desde la web de su autor: SLURM 0.3.3
Una vez instalado (1 - ./configure 2 - make 3 - make install) podemos empezar a monitorizar el tráfico ejecutando slurm de la siguiente manera: slurm -i eth0.
A continuación podéis ver una captura de SLURM en uno de mis servidores.
Click here to translate this post
Optimizar MySQL puede resultar muy importante si disponemos de una BBDD en donde la cantidad de registros va aumentando considerablemente. Pongamos por ejemplo una página web donde tenemos un script que guarda en una tabla de MySQL información de cada visitante.
La tabla es muy sencilla:
create table visitas(id int(9) auto_increment primary key, ip varchar(15), fecha = datetime);
El script se encarga de asegurarse de únicamente insertar un nuevo registro en la tabla en el caso de que esta sea la primera visita del usuario en las pasadas 24 horas. Para lograrlo primero realizamos el siguiente SELECT:
SELECT COUNT(*) FROM visitas WHERE ip = ‘xxx.xxx.xxx.xxx’ AND fecha BETWEEN ‘YYYY-MM-DD 00:00:00′ AND ‘YYYY-MM-DD 23:59:59′;
Si el query nos devuelve 1 significa que este visitante ha accedido a la web hace menos de 24 horas, por lo que no insertamos un nuevo registro.
Si el query nos devuelve 0 procedemos a realizar un INSERT con la información del visitante.
INSERT INTO visitas SET ip = ‘xxx.xxx.xxx.xxx’ AND fecha = NOW();
Este código y tabla de MySQL funcionan bien siempre y cuando tengamos una web con pocas visitas. El SELECT para comprobar si el usuario ha visitado la web recientemente se ejecuta en una media de 0.00 sec si tenemos pocos registros. ¿Qué sucede si las visitas a nuestra web aumentan y tenemos miles de usuarios conectándose diriamente? Nuestra tabla visitas pasa de tener unos pocos miles de registros a millones. Si realizamos el mismo select en una tabla con 2 millones de registros nuestros tiempos de espera aumentan a cifras inaceptables.
mysql> SELECT COUNT(*) FROM visitas WHERE ip = ‘xxx.xxx.xxx.xxx’ AND fecha BETWEEN ‘YYYY-MM-DD 00:00:00′ AND ‘YYYY-MM-DD 23:59:59′;
+———-+
| COUNT(*) |
+———-+
| 0 |
+———-+
1 row in set (4.45 sec)
Si por cada visita MySQL tarda 4.45 segundos en devolver el resultado el servidor quedará totalmente colapsado.
La solución a este problema es bien simple. Tan sólo debemos de hacer uso de índices (Indexes). Gracias a los índices MySQL no tiene que realizar la búsqueda desde el primer a último registro.
Crearemos un índice de la columna ip.
mysql> CREATE INDEX ip ON visitas (ip);
Query OK, 2008402 rows affected (53.75 sec)
Records: 2008402 Duplicates: 0 Warnings: 0
Si ahora realizamos el anterior SELECT, que sin el índice tardó 4.45 en devolver el resultado, comprobamos que lo devuelve en 0.03 segundos.
mysql> SELECT COUNT(*) FROM visitas WHERE ip = ‘xxx.xxx.xxx.xxx’ AND fecha BETWEEN ‘YYYY-MM-DD 00:00:00′ AND ‘YYYY-MM-DD 23:59:59′;
+———-+
| COUNT(*) |
+———-+
| 0 |
+———-+
1 row in set (0.03 sec)
El uso de índices es sumamente importante para optimizar una BBDD MySQL. Es una buena idea comprobar que ningún SELECT de vuestra web/aplicación tarda demasiado en devolver los resultados. Si así es, lo más probable es que no disponga de ningún índice.
Para más información: Web oficial MySQL sobre índices
Click here to translate this post
Si quieres que Apache redireccione la ruta de un dominio a otro utiliza el siguiente código en un archivo .htaccess:
RedirectMatch permanent (.*) http://dominio2.com$1
Este archivo tiene que estar en la raíz del DocumentRoot del dominio.
Gracias a este código, si por ejemplo un usuario accede a http://dominio1.com/carpeta1/test.php, automáticamente será redireccionado a http://dominio2.com/carpeta1/test.php
Click here to translate this post
En este ejemplo mostraré cómo tener dos dominios atacando a una misma BBDD WordPress MU.
WordPress MU guarda el nombre de dominio en la BBDD para cada blog nuevo. Cuando se accede a un blog de WordPress MU, éste busca la información sobre el blog comparando el subdominio y dominio con el registro en la BBDD.
Imaginemos que tenemos el dominio www.dominio1.com y un usuario crea un blog llamado blogpersonal. La ruta para el blog sería http://blogpersonal.dominio1.com. En el momento en que alguien acceda a ese blog, WordPress realizará la búsqueda blogpersonal.dominio1.com en el campo domain de la tabla wp_blogs. En el caso de que exista se le presentará el blog con su plantilla correspondiente.
¿Qué pasa si queremos que otro dominio ataque a la misma BBDD? Configuraremos Apache para que la ruta del DocumentRoot de www.dominio2.com sea la misma que el domino www.dominio1.com. De esta forma conseguimos que ambos dominios compartan los mismos archivos. Si volvemos a acceder a http://blogpersonal.dominio1.com WordPress nos devuelve el blog correctamente. Si accedemos a http://blogpersonal.dominio2.com WordPress nos informa de que el blog no existe. Este resultado se debe a que WordPress ha buscado blogpersonal.dominio2.com en el campo domain de la tabla wp_blogs y ese registro no existe.
Para solucionar este problema tenemos que editar todas aquellas funciones que realicen la búsqueda del blog en la BBDD. El código PHP es muy sencillo:
$domain = $_SERVER[’HTTP_HOST’];
$domain2 = strpos($domain, ‘domain2′);
if($domain2 > 0){
$output = str_replace(”domain1″, “domain2″, $output);
}
Este código mira si el dominio es dominio2.com y en el caso de que lo sea le cambia el nombre a dominio1.com. Por lo que blogpersonal.dominio2.com pasaría a blogpersonal.dominio1.com y WordPress sí encontraría el registro en la BBDD.
En este archivo, WP_MU-Multidominio, PHP encontrarás todas los ficheros que debes editar para que WordPress MU pueda funcionar con más de un dominio.