carpclash

Tras leer el interesante libro de Steve Souders High Performance Web Sites, Essential Knowledge for Front-End Engineers  me dispuse a realizar tareas de Optimización en una aplicación web con alto tráfico. El siguiente artículo pretende dar cuenta de algunas prácticas que desarrollé y de cómo éstas me permitieron una carga más veloz al tiempo en que liberaron a mi servidor de una cantidad considerable de Requests.Introducción a los HTTP RequestsPara comenzar, expliquemos brevemente qué son los HTTP Requests y qué sucede en nuestro servidor cuando un visitante solicita, por ejemplo, nuestro Homepage ingresando la url del sitio en su navegador y dando Enter. Usando palabras de Steve Souders:"HTTP es un protocolo cliente/servidor constituido por Solicitudes y Respuestas. Un navegador envía una solicitud HTTP a una url específica y el servidor que almacena los contenidos de esa URL responde, también mediante HTTP".Explicar en detalle cómo funciona el protocolo HTTP requeriría un artículo aparte, pero es altamente recomendable comprender el funcionamiento de este protocolo dado que es el encargado de negociar la interacción entre nuestros visitantes y nuestro servidor.A nuestros fines y simplificando muchísimo el proceso, diremos que cuando un visitante escribe nuestra URL e ingresa a nuestro sitio el navegador envía un Request inicial para acceder a nuestro HTML. Si todo funciona bien, el servidor responde OK (HTTP/1.1 200 OK).Una vez que el navegador ha obtenido una respuesta del tipo OK al DOM de nuestra web, procede a recorrer nuestro código en busca de los elementos que constituyen nuestra web. Cada vez que se encuentra un elemento invocado (por ejemplo, una hoja de estilos, un script js o una imagen) el navegador vuelve a enviar un Request, que el servidor deberá responder al tiempo en que devuelve el contenido solicitado.Explicado esto, es justo decir que para que nuestro sitio esté 100% disponible al visitante, el servidor debe responder a tantos Requests como componentes tenga nuestro sitio + 1. Esto, como podrán imaginarse, es lo que determina la velocidad con que nuestro sitio responderá. Si tenemos llamados a 3 hojas de estilo, 3 Scripts js, 5 imágenes llamadas explicitamente vía <img> nuestro servidor deberá responder a 1 Request inicial + 11 Requests de contenidos + Requests que puedan provenir de imágenes invocadas vía CSS en las hojas: cada background: url(path/to/image), es 1 Request más a responder.Antes de continuar, demos un vistazo a qué sucede con nuestro sitio cuando alguien solicita una página haciendo uso de una excelente herramienta Online llamada WEBPAGETEST . Introduzcan allí su URL y estudien el informe.Economizando los HTTP RequestsLa primera medida a tomar para Optimizar la carga de un sitio web es reducir los Requests que nuestro servidor deberá responder. Para esto, disponemos de muchos métodos. Siguiendo a Souders veremos algunos:1- Usar CDNsLas CDNs o Content Delivery Networks son redes de servidores distribuídos geográficamente que sirven contenido a un visitante utilizando el servidor más próximo a él en función de su IP. El ejemplo más común es la CDN de Google API que nos permite invocar librerías o scripts desde sus servidores ahorrándole a nuestro Host la respuesta y servido de ese contenido (hay que aclarar, aunque obvio, que nuestro servidor al responder OK a un request luego debe presentarlo y esto implica uso de nuestro Bandwith).Mi sitio trabaja con Jquery y Jquery UI (que a su vez incluye estilos e imágenes del theme que uno use). Todo este contenido puede ser descargado de los sitios de Jquery y Jquery UI respectivamente y puesto a funcionar en nuestro servidor, pero: ¿qué sentido tiene esto si podemos llamar los 2 paquetes y sus componentes desde la CDN de Google?- http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/smoothness/jquery-ui.css - http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js - http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js Llamando a Jquery y Jquery UI con sus estilos desde Google le ahorraremos una cantidad considerable de HTTP Requests a nuestro servidor (especialmente por los estilos del theme de JqueryUI y sus imágenes).2- Minificar y unirLa minificación es la práctica mediante la cual se remueven espacios innecesarios en un script para hacerlo más liviano (Si miran los links de las CDN de Google para Jquery podrán ver un ejemplo). La minificación es utilizada especialmente con scripts JS y existen múltiples sitios que permiten minificar un script online ahorrándonos la tediosa tarea de hacerlo manualmente como http://jscompress.com/ El pro de esta práctica: archivos más livianos lo cual equivale a menor ancho de Banda. La contra: los archivos se convierten  en una línea críptica de código muy poco legible por lo que es recomendable conservar el archivo original para introducir futuros cambios y luego minificar y subir.La minificación nos ahorrará ancho de banda achicando el tamaño de los scripts pero no nos resuelve en nada la cantidad de HTTP Requests. Para esto una solución muy sencilla: unir scripts de modo de llamar la menor cantidad posible. Muchas veces sucede que en el proceso de desarrollo y manteniemiento de un sitio web agregamos nuevas funcionalidades y simplemente pegamos en el head de nuestra web las llamadas a los nuevos Scripts JS y estilos CSS: todo funciona bien y así se queda.Si tu sitio está llamando más de 2 scripts desde tu Servidor o invoca más de 1 hoja de estilos es tiempo de preguntarte si no podrás unir los scripts en 1 solo fichero. Te sorprenderá saber que fusionar 3 hojas de estilo en 1 darán un archivo CSS que pesará menos que las 3 hojas sumadas al tiempo en que ahorrás 2 Responses al Servidor.3- Trabajar con Sprites CSS Esto es tan simple como suena. Si tu hoja de estilos llama 5 imágenes distintas vía background: url(path/to/image) entonces tu hoja de estilo le está diciendo al Navegador que envíe 5 Requests para obtener las imágenes.La solución, nuevamente, es muy simple: junta las 5 imágenes en 1 sola, llamala 1 vez con background: url(path/to/image) y luego utiliza background-position para localizar cada una de las 5 imagenes en tu Sprite. El resultado: 4 HTTP REQUESTS menos y la sorpresa de ver que la imagen conteniendo las 5 imágenes es más liviana que la suma de las 5 por separado.Puedes armar tus Sprites con Photoshop o bien probar alguna herramienta para armar sprites Online como CSS Sprite Generator en que subes un zip con todas las imágenes que usas en tu CSS por separado y obtienes una imagen única lista para ser usada.Trabajando con Amazon S3Finalmente y dándole sentido al título de este artículo usaremos el servicio de almacenamiento de Amazon ( Amazon Simple Storage Service o S3) . Se trata de una solución económica (uno paga por lo que usa) y fiable para almacenar archivos de forma transparente para nuestros usuarios y visitantes. Amazon S3 es altamente recomendable para manejar una gran cantidad de archivos sin utilizar el Bandwith de nuestro servidor: imágenes, textos, scripts, css, etc.Si, por ejemplo, el sitio web que queremos optimizar permite a los visitantes crearse una cuenta y subir una imagen de usuario, el uploader enviaría esta imagen a S3 y la mostraría luego cada vez que sea necesario desde el Bucket que creamos en S3 (en mi caso no sólo permito a mis usuarios cargar un avatar sino que éstos pueden subir documentos de hasta 10MB cada uno). Amazon S3 es, simplemente la solución correcta: nos ahorra los HTTP Requests (que son enviados a sus servidores), nos ahorra una cantidad de Bandwith que dependerá de qué clase de uploads permitamos y, por último y totalmente desvinculado del tema Optimización, cubre un potencial agujero en la seguridad anulandoló por completo al enviar todo a S3 de suerte tal de que si alguien se las ingenia para falsear el sistema de control de extensiones de archivos o sube una shell como la C99 con formato .txt y  encuentra un modo de renombrarla habrá subido un archivo .php a un servidor que no interpreta PHP: la shell es obsoleta y el atacante ha perdido su tiempo.Les dejo un link a una clase en PHP para gestionar Subidas a Amazon S3 llamada Amazon S3 PHP Class . Es una clase interesante para comenzar aunque pueden encontrarse uploaders con progress bar y demás características que funcionan con S3.Yo he dado un paso más en el uso de S3: subi hojas de estilos, imágenes usadas por ellas y scripts de js. En sintesis, mi servidor responde al primer Request con 200 y luego el navegador del visitante comienza a enviar Requests a la CDN de Google y a S3. Creanmé que carga rápido!¿Pero y si Amazon S3 se cae?Esta es una interesante pregunta. Mi respuesta es la siguiente: tanto en estos menesteres como en otros, siempre está preparado para que las cosas fallen con un plan B. En lo que refiere a los ficheros JS, CSS e imágenes asociadas a los estilos no tengo nada en S3 que no tenga en mi servidor. Simplemente uso la versión de S3 pero sólo cambiando un valor en el fichero de configuracion de mi aplicación todo lo que se llama de S3 pasa a llamarse de local.En lo que refiere a archivos pesados de usuarios o de la propia aplicación (Documentos, Videos, Imágenes o lo que sea que uno haya delegado) sería irresponsable pensar que S3 nunca fallará por lo que es recomendable tener una réplica en otro servidor y un mecanismo similar al descripto antes para que los archivos que se llaman desde S3 se llamen desde la réplica. Cómo mover los archivos de S3 al servidor réplica es un tema a conversar dado que seguramente existen programas que permitan esto o, inclusive, uno podría codear su propio script que mantenga sincronizados los archivos.Yo he optado por una solución de otra clase: uso 2 buckets en 2 locaciones distintas (USA y Singapur) y sincronizo los contenidos con Cloudberry Explorer for Amazon . Mi circuito diario es: Bucket 1 -> HDD Local -> Bucket 2 ,de modo de tener una copia de todos los archivos en mi PC y en el segundo Bucket (en caso de que el servicio completo de Amazon S3 vuele por el aire y ningún servidor responda).ConclusionesEl libro de Steve Souders High Performance Web Sites, Essential Knowledge for Front-End Engineers es de lectura recomendable y encontrarán en el muchas buenas prácticas para Optimizar la Performance de sus sitios que aquí no se han tratado.Nos hemos limitado a tomar algunos de sus consejos y a usar CDNs y S3 para servir contenido. Esto le hace a nuestro servidor la vida más facil, pero sin las prácticas de Minificación, Unión de Scripts y Hojas de Estilo y Uso de Sprites aquí mencionadas, aunque llamemos los componentes de nuestra web desde S3 tendremos la misma cantidad de Requests (con Responses de Google o S3, lo cual puede mejorar el tiempo de las respuestas pero no las reducirá en número).Dicho esto, queda claro que una correcta optimización requiere necesariamente la reducción de Requests enviados por el navegador. Antes de optimizar les recomiendo correr el test Online de WEBPAGETEST y verificar la cantidad de REQUESTS enviados para tener un parametro con que medir el éxito de la Optimización.Publicado originalmente en mi Blog:

IntroducciónEste artículo está destinado a quienes han optado por comenzar con Linux y se encuentran -finalizada la instalación de la distribución elegida- por primera vez con lo que podríamos llamar el árbol o estructura típica de directorios de los sistemas operativos Linux . En mi opinión este "primer encuentro" del usuario que ya ha cristalizado la estructura de archivos de Windows, puede ser muy frustrante: se trata de usuarios con una idea más o menos formada de dónde están las cosas en sistemas Windows. Saben que los ficheros de configuración se localizan en (C:\Windows y C:\Windows\System32\64 más específicamente). Conocen además que los programas que han instalado a través de Install Wizards crean carpetas generalmente en C:\Archivos de Programas y que pueden encontrar sus documentos y descargas en C:\Documents and Settings.No recuerdo con exactitud el año en que instalé por primera vez Linux aunque podría arriesgar que ésto sucedió en el 1997/98.  Mi distribución elegida entonces fue Slackware (a sabiendas de que era de las más complicadas, quería algo simil UNIX -en rigor, creo que me dieron ese CD y no tuve muchas alternativas-). En aquellos tiempos hacer un Dual Boot con Windows y Linux no era tan simple como hoy debido a que Linux no contaba aún con instaladores gráficos de esos que nos guían practicamente a lo largo de toda la instalación y el Windows de entonces podía con suerte bootearse a si mismo.  Logré -con la ayuda de un amigo linuxero- instalar Linux junto con un Windows (95 o 98, supongo).Nunca voy a a olvidar el desequilibrio que senti cuando ingresé a Slack por primera vez, me logueé root, hice startx y abrí el explorador de archivos. Mi amigo se habría ido para ese momento porque recuerdo que navegando las carpetas del sistema llegaba al / para encontrarme con un conjunto de directorios del que sabía absolutamente nada. Vale aclarar que en éstos tiempos  yo no tenía aún Dial up en mi casa y la comunidad Linux era un germen de lo que es hoy en día.En la actualidad Google puede proveer información acerca de lo que sea que queramos entender, pero aún así intentaré en este artículo explicar al usuario que llega de Windows la arquitectura de los ficheros que componen éste enorme sistema operativo llamado Linux como me hubiera gustado que me lo expliquen aquel día.Puesta esta introducción, comencemos  sin más con nuestro cometido.LNW: Linux no es WindowsMe voy a permitir la licencia de jugar con este concepto. En la comunidad del Software Libre Richard Stallman (un personaje con que estoy de acuerdo con reservas y a quien considero muy sobrevalorado si tenemos en cuenta con qué contribuyó al mundo de Linux y la posición que ocupa en los medios de comunicación) introdujo el concepto de GNU (GNU is not Unix) para distinguir a Linux en tanto sistema operativo libre de Unix, el sistema operativo a partir del cual Linus Torvalds creó el primer Kernel Linux (si sabés que fue Minix y no Unix quizás este artículo no esté dirigido a vos).Linux no es Windows significa que, tenemos que hacer un esfuerzo tan grande como podamos para olvidar el modo en que Windows se estructura y actua -intentar poner nuestra mente en Tabula rasa , como diría Locke- y preparanos para un sistema operativo que nos brindará lo mismo y más que Windows, pero de otro modo. Si bien las interfaces gráficas (Gnome/KDE  y otras) con que Linux cuenta hoy en día son muy intuitivas para un usuario de Windows, no tardaremos en entender que estás interfaces gráficas corren sobre una estructura totalmente distinta a la acostumbrada en Windows y, a diferencia de la experiencia que podamos tener con el OS de Microsoft, en Linux vamos a encontrarnos con la consola de comandos muy rapidamente. Esto es importante desde que la mayoría de usuarios de Windows en su vida han ejecutado el comando cmd (sí, es la mayoría).Dicho esto, rebooteamos nuestra cabeza y vamos a explicar la arquitectura de Linux y la función de los componentes que la integran.El Arbol de Directorios en Sistemas LinuxEn resumen, un SO Linux posee una serie de directorios que conforman el sistema de archivos. Estos pueden crearse en una misma partición o disco (los instaladores gráficos de distribuciones actuales recomiendan este esquema para los nuevos usuarios) así como en distintas particiones o discos rígidos. Independientemente del esquema que elijamos (instalar todos los directorios en una misma partición o en distintas) veremos siempre el listado del árbol de directorios como si éstos estuvieran en un mismo disco/partición.1- La raíz del sistema "/": en Linux el punto más alto en el árbol de directorios es lo que se denomina root. Podríamos pensarlo como el C:\ de Windows pero con la distinción de que en Windows podemos tener otras unidades (otros HHDD o lectoras DVD) que se listarán con otra letra como separados de C:\ en tanto que en Linux cualquier componente estará siempre ubicado en algún punto debajo de la "/".2- El directorio /bin: este fichero contiene binarios ejecutables (es decir, archivos que en windows serían .exe) requeridos en el proceso de boteeo del sistema y utilizados normalmente por los usuarios. Si listamos los archivos de este directorio entenderemos facilmente de qué hablamos: allí residen programas como ls, tar, mkdir, rm, cp y -en líneas generales- ejecutables que utlizamos constantemente en consola.3- El directorio /boot: archivos utilizados en el proceso de booteo del sistema. Encontraremos aquí a nuestro booteador (GRUB o LILO). Este fichero es lo primero que el sistema operativo analiza una vez se ha arrancado la PC y establecido comunicación con el sistema operativo. Generalmente tendremos aquí además una versión comprimida de nuestro Kernel con nombre vmlinuz (en mi Debian Squeeze vmlinuz-2.6.32-5-amd64)4- El directorio /dev: al introducir la raíz del sistema hablamos de que en Linux -a diferencia de Windows- las unidades de almacenamiento y periféricos en general no se listaban en paralelo a la "/", sino que estaban en algún punto debajo de ésta. Este punto es, en concreto, el fichero dev cuya misión es la de abstraer los dispositivos de Hardware brindando archivos que permitan manipularlos para cada caso. Si corremos ls en este directorio encontraremos allí archivos que hacen referencia a nuestra lectora DVD, discos rígidos y demás periféricos de que dispongamos. Vale aclarar que dev es abreviatura de devices o dispositivos en español.5- El directorio /etc: este directorio contiene los archivos de configuración de los programas que nuestra distribución traiga y de aquellos que instalemos. Es común que al instalar un nuevo programa en Linux se cree (o uno deba crear manualmente) una carpeta en este directorio que contiene los archivos mediante los cuales podemos controlar el comportamiento del programa en cuestión. Un ls a este directorio nos mostrará carpetas tales como apt, apache2, php5, mysql y demás aplicaciones que posean archivos de configuración editables por el usuario.6- El directorio /home: aquí encontraremos los ficheros de los usuarios creados en el sistema operativo. Por lo pronto, durante el proceso de instalación de tu Linux , habrás creado un usuario root y un usuario con que utilizarás el sistema operativo por defecto  (/home/miusuario). Al bootear tu Linux ingresarás a la interface gráfica y los programas de que esta dispone con los datos de tu usuario no root. Recordemos que Linux es un sistema multiusuario (esto es, pueden haber 5 usuarios distintos en la misma máquina en el mismo momento) y mantiene la información de cada usuario aislada dentro de subdirectorios en home. Cada usuario creado dispone de su carpeta dentro de /home/nombredeusuario en que puede guardar información y configuraciones generales (de la interface gráfica por ejemplo) a la que sólo tendrá acceso él mediante su user y pass. Este es uno de los puntos fuertes de Linux desde hace tiempo. Vale aclarar que el usuario root puede acceder a los datos de cualquier usuario.7- El directorio /lib: este fichero almacena librerías compartidas  para programas del  sistema operativo y módulos del kernel.8- El directorio /mnt: este fichero oficia como punto de montaje para dispositivos tales como lectograbadoras de DVD, USB sticks, particiones de otros OS, etc. Si bien las distribuciones de hoy en día automontan DVDS o USB sticks en la carpeta /media en el pasado (cuando instalé mi primer Slackware,  por ejemplo) uno debía montar manualmente cualquier periférico a través del comando mount y el punto para dicho montaje era siempre el directorio /mnt. Si tenemos un Dual Boot y queremos que nuestras particiones de Windows estén disponibles en Linux podemos montarlas para que se carguen en el proceso de Booteo siguiendo estas instrucciones . Vale aclarar que el tutorial monta en /mnt, pero las particiones podrían ser montadas en cualquier otro sitio (/home/miuser/windows, por ejemplo). Lo cierto es que en distribuciones como la mía (Debian Squeeze) en que al introducir un DVD o un Stick USB el proceso de montaje se raliza automáticamente en /media el directorio /mnt parecería estar presente nada más que por romanticismo. Por suerte soy un romántico y he montado todos mis discos/particiones NTFS en él 9- El directorio /root: el rincón del administrador. Este fichero es al usuario root lo que a un usuario no root su fichero /home/nosoyroot. Tiene como finalidad brindarle al administador un espacio propio para trabajar y almacenar separado de los directorios del sistema y de los subdirectorios de usuarios con privilegios inferiores en /home.10- El directorio /sbin: más ejecutables (binarios de sistema o system binaries). Este directorio extiende  la lista de programas disponibles en /bin para ser corridos desde consola, pero  en este caso son programas cuya utilización suele estar reservada para el root user. Un ls al directorio nos mostrará programas como iptables o shutdown que sólo deben estar al alcance de un superusuario o root (imaginen un Linux con 5 usuarios trabajando en que uno de los 5 pudiera apagar el sistema ... not good mate =).11- El directorio /proc: este directorio provee información sobre el sistema. Podemos, por ejemplo, obtener información sobre nuestro procesador corriendo cat /proc/cpuinfo. Es interesante observar que se trata de archivos inexistentes en el rígido que son llamados desde la memoria RAM. Hagan un ls al dir para ver su contenido y luego un ls -l para ver el peso de los archivos que ls acaba de listar. OMG! 12- El directorio /usr: este directorio es como "un lugar más" en que se situan archivos que bien podrían ir en /sbin o /lib. Dicho esto, encontraremos aquí más ejecutables, más librerías, más código fuente (src), mucha documentación acerca de los programas contenidos, etc. Un ls de este directorio nos permitirá ver que, a diferencia de los mencionados anteriormente, aquí poseemos una estructura de subdirectorios que a su vez contienen mucha información. Si tu Linux vino con una serie de programas instalados, éstos se ejecutan -en la mayoría de los casos- desde este directorio. El Konqueror, por ejemplo, tiene su ejecutable en /usr/share/applications/kde4 (uso KDE ¿y qué?)13- El directorio /var: por último, el directorio var -cuyo nombre proviene de variable- almacena una serie de archivos  que, como su nombre lo indica, suelen ser variables. Aquí encontraremos archivos de logs de diversas aplicaciones en constante cambio desde que la actividad en cada aplicación los modifica agregando información de su funcionamiento. Este directorio suele ser el destinado al alojamiento de sitios web (de hecho contiene por defecto una subcarpeta llamada /www). Es importante comprender que, con la excepción de los directorios de usuarios en /home y superusuario en /root, el resto de los directorios que hemos visto suelen mantenerse sin alteraciones (al menos si no instalamos o actualizamos) por lo que un directorio como /var es preciso dado que toda la actividad del sistema debe imprimir huellas en algún sitio y lo hace aquí.Aclaraciones finalesTenemos la obligación de aclarar que -como es evidente- no hemos hecho más que describir superficialmente los contenidos de cada uno de los directorios que configuran el sistema de archivos en Linux . Sin embargo, se trata de una breve introducción a una "nueva forma de pensar los cimientos del sistema operativo que utilizaremos" con que me hubiera gustado contar cuando por vez primera le di click al "subir nivel" hasta el root de mi Slackware y me encontré con esta colección de carpetas en que no estaban ni Documents and Settings ni Application Data.Quizás quienes se inician en el mundo de Linux puedan leer esta pequeña introducción y comenzar a utilizar este gran sistema operativo comprendiendo su estructura mejor de lo que llegaron a entender lo que tuvieron bajo C: durante años. Ojalá así sea.Este post fue pubilicado originalmente en mi Blog:

Este artículo es el segundo en la serie De Windows a Linux cuyo fin es el de "introducir algunas de las funcionalidades básicas" de Linux a usuarios que han decidido dar el primer paso en la dirección de migrar de Windows a alguna distribución de este poderoso Sistema Operativo. En la edición anterior hemos intentado familiarizar al nuevo usuario con la estructura de archivos en OS Linux, desarrollando brevemente qué función cumplía cada uno de los directorios que componen una distribución Linux standard. En esta oportunidad comenzaremos a estudiar otro aspecto que puede resultar complejo para los nuevos usuarios: Linux como sistema multiusuario, administración de los usuarios y -lo más importante- de los permisos para los contenidos generados por cada usuario del sistema. Breve Introducción Cuando decimos que Linux es un OS Multiusuario aludimos a que distintos usuarios pueden trabajar simultaneamente sobre un mismo sistena operativo, cada uno con su cuenta. En este artículo vamos a crear un nuevo usuario nada más que para explicar el proceso mediante el cual la privacidad de la información de cada user puede ser manipulada a través del sistema de permisos en Linux. Se trata de un aspecto fundamental de los sistemas Linux (y en líneas generales de todos los otros que nacen a partir de UNIX). Para no ofuscar la misión de este artículo apelaremos a un ejemplo cotidiano que cualquier lector podrá entender rápidamente. Hemos instalado alguna distribución de Linux en la PC de casa. Disponemos de la cuenta root de esa distro, además de la de nuestro user no root creado durante la instalación. Ahora bien, tenemos 1 hermano que también quiere usar la PC y no nos interesa para nada que éste pueda acceder a nuestra información o configuración (no lo queremos por ahi toqueteando los tweaks de nuestra interface gráfica que tan linda nos quedó, ni queremos que pueda acceder a nuestros documentos, descargas, etc, etc). Por fortuna Linux nos permitirá crearle a este hermano su propia cuenta de usuario, lo cual creará para él un nuevo directorio /home/eluserdelhermano en que podrá almacenar sus archivos, descargas, definir si quiere usar KDE o Gnome y configurarlo con un wallpaper que seguramente no será de nuestro agrado ;=1 Creando un Usuario para nuestro Hermano Comencemos por crear la cuenta del nuevo usuario. Vamos a llamarlo "hermano" y la crearemos desde la consola porque nos interesa comenzar a familiarizarnos con este entorno en que trabajaremos seguido. Para poder dar de alta un nuevo usuario tendremos que loguearnos como root tal cual se describe a continuación. carp@home:/$ su root Contraseña: root@home:/# adduser hermano Añadiendo el usuario `hermano' ... Añadiendo el nuevo grupo `hermano' (1002) ... Añadiendo el nuevo usuario `hermano' (1002) con grupo `hermano' ... Creando el directorio personal `/home/hermano' ... Copiando los ficheros desde `/etc/skel' ... Introduzca la nueva contraseña de UNIX: elegimosunaclave Vuelva a escribir la nueva contraseña de UNIX: repetimoslaclave passwd: contraseña actualizada correctamente Cambiando la información de usuario para hermano Introduzca el nuevo valor, o presione ENTER para el predeterminado Nombre completo []: Mi hermano Número de habitación []: Teléfono del trabajo []: Teléfono de casa []: Otro []: ¿Es correcta la información? [S/n] S root@home:/# Una lectura del output del comando adduser nos dice con toda claridad qué ha sucedido. 1) Se ha creado un nuevo usuario (hermano) 2) Se ha creado un nuevo grupo (hermano) 3) Se ha creado el directorio para este usuario (/home/hermano) 4) Se nos pide una clave que debemos proporcionar 5) Se nos pide información que podemos brindar o no (en mi caso solo puse el nombre y luego enter en el resto de los campos). 6) Se nos pide confirmar los datos y con esto el usuario se ha creado. Podemos ya mismo ir a nuestro menu buscar salir o leave y luego elegir switch user/cambiar usuario para reingresar con el usuario hermano y la clave elegida y comprobar que allí está el escritorio vacío tal cual lo vimos cuando ingresamos por primera vez al entrar con nuestro user no root. Vale aclarar que, la sesión en que estabamos trabajando antes de cambiar de usuario sigue activa y podemos regresar a ella cuando lo deseemos. Definiendo Permisos en nuestros contenidos Ahora bien, nos bastará con buscar un explorador de archivos estando conectados con la cuenta hermano para comprobar que éste tiene acceso a nuestro home y puede subir de nivel inclusive hasta el / (raíz del sistema) y leer el contenido de algunos ficheros de configuración importantes pero no modificarlos. En líneas generales Linux no permitirá que un nuevo usuario pueda modificar ficheros vitales para el sistema reservando esta tarea para el usuario Root. Puede sucedernos sin embargo que no deseamos que el usuario hermano tenga acceso al listado de directorios de nuestra carpeta de user no root /home/carp o, por el contrario, que necesitamos que pueda ejecutar cosas (programas) que se encuentran allí y sobre los cuales no tiene permisos de ejecución. De este modo, vamos a introducirnos en el mundo de los permisos y veremos cómo manipularlos. Entendiendo los Permisos y sus destinatarios Comencemos por realizar un ls -l (ls -l es flag para large y listará los directorios en formato largo, es decir, con todos los detalles) en el directorio /etc y tomemos las primeras líneas de la salida. hermano@nodo0:/$ ls -l /etc total 1288 drwxr-xr-x 3 root root 4096 oct 3 21:47 acpi -rw-r--r-- 1 root root 2981 oct 3 21:46 adduser.conf -rw-r--r-- 1 root root 47 dic 17 22:17 adjtime drwxr-xr-x 2 root root 4096 nov 23 16:02 akonadi -rw-r--r-- 1 root root 196 oct 4 00:03 aliases drwxr-xr-x 2 root root 16384 dic 15 21:48 alternatives -rw-r--r-- 1 root root 395 nov 1 2009 anacrontab drwxr-xr-x 7 root root 4096 oct 4 19:21 apache2 Este comando en su versión large (-l) nos muestra detalles sobre cada directorio y archivo dentro de /etc. A los fines de comprender los permisos nos interesa: Permisos User Grupo Nombre drwxr-xr-x 7 root root 4096 oct 4 19:21 apache2 Tipos de permisos Los permisos existentes en Linux son Read (lectura), Write (escritura), Execution (ejecución) y se otorgan a 3 clases de usuarios del sistema: Creador del archivo o directorio (Owner), Usuarios pertenecientes al grupo del creador (Group), Otros usuarios que no son ni el creador ni pertenecen a su grupo (Others). Para cada uno de estos 3 tipos de usuario, deben definirse permisos de modo que el sistema sepa quienes tienen o no acceso a qué tareas. Es así que los permisos de la carpeta apache2 deberían leerse así: drwxr-xr-x 7 root root 4096 oct 4 19:21 apache2 d: es un directorio rwx: el creador u owner (root, según el ls, posee todos los permisos). r-x: otros usuarios en el grupo root pueden listar los archivos del directorio y acceder al mismo. r-x: otros usuarios que no sean el creador ni pertenezcan a su grupo pueden listar los archivos del directorio y acceder al mismo. Una cosa que suele generar confusión cuando intentamos comprender los permisos es que éstos significan distintas cosas dependiendo de si se trata de un archivo o un directorio. Las diferencias son las siguientes: Ficheros: r = permiso para leer el contenido del archivo w = permiso para modificar el contenido x = permiso para ejecutar el archivo Directorios: r = permiso para listar los archivos del directorio w = permiso para crear o eliminar archivos en el directorio x = permiso para acceder al directorio Al listar con ls -l los contenidos de un directorio, el primer caracter de la lista de permisos nos dirá si se trata de un archivo (-), un directorio (d), o un link (l). Por ejemplo: -rw-r--r-- 1 root root 662 dic 15 21:21 hosts (el primer caracter es un "-": se trata de un archivo). drwxr-xr-x 7 root root 4096 oct 4 19:21 apache2 (el primer caracter es una "d": se trata de un directorio). lrwxrwxrwx 1 root root 13 oct 3 21:46 motd -> /var/run/motd (primer caracter "l", link) Modificando los Permisos Habiendo logrado comprender cuáles son los tipos de usuarios y permisos que debemos tener en cuenta a la hora de conocer los privilegios de cada user, veremos cómo modificar estos permisos. Empezaremos con un ejemplo práctico: el usuario hermano puede acceder a los contenidos de mi carpeta (carp) en /home/carp. Veamos un listado de como están los permisos en /home carp@nodo0:/$ ls -l /home total 116228 drwxr-xr-x 63 carp carp 4096 dic 22 18:30 carp drwxr-xr-x 2 ftp nogroup 4096 dic 7 15:26 ftp drwxr-xr-x 15 hermano hermano 4096 dic 23 00:23 hermano carp@nodo0:/$ Según vimos unas líneas más arriba cuando distinguimos el significado de los permisos Read, Write y Execute en archivos y directorios, el directorio /carp tiene todos los permisos para su owner (es decir, yo), y luego tiene permisos de lectura y ejecución tanto para el grupo carp como para el resto de los usuarios. Visto y considerando que no queremos que el usuario hermano pueda listar los contenidos de /home/carp necesitaremos remover el permiso x (Ejecución, que en directorios permite acceder) del tipo de usuario others, dado que el user hermano no forma parte de mi grupo. Es decir necesitamos que los permisos queden: drwxr-xr-- 63 carp carp 4096 dic 22 18:30 carp Para esto utilizaremos el comando chmod con la siguiente sintaxis: carp@home:/$ chmod o-x /home/carp carp@nodo0:/$ Si volvemos a listar los contenidos de /home con ls -l: carp@home:/$ ls -l /home total 116228 drwxr-xr-- 63 carp carp 4096 dic 22 18:30 carp drwxr-xr-x 2 ftp nogroup 4096 dic 7 15:26 ftp drwxr-xr-x 15 hermano hermano 4096 dic 23 00:23 hermano carp@nodo0:/$ Y si el usuario hermano intenta acceder a nuestro directorio: hermano@nodo0:/$ cd /home/carp bash: cd: /home/carp: Permiso denegado hermano@nodo0:/$ Ahora bien, analicemos el modo en que utilizamos el comando chmod (chmod o-x) decomponiéndolo. chmod o-x = chmod [ usuario ] [ operacion ] [ permisos ] Es decir que estamos pidiendo que a los usuarios others (o) se le quite (-) permiso de ejecucion (x) sobre el directorio. Si cambiaramos el signo de - por + de modo que el comando fuera chmod o+x, restauraríamos el permiso que acabamos de remover. Las opciones para este comando son: a = all users u = user g = group o = others Veamos algunos ejemplos: chmod a+x /home/carp (le da a todos permiso de ejecución sobre /home/carp) chmod o-rx /home/carp (le quita al user others permisos de lectura y ejecución) chmod o+rwx /home/carp (le da a others todos los permisos sobre el dir /carp. Una muy mala idea!) Vale aclarar que el usuario carp puede alterar los permisos del directorio carp porque según vimos en el listado obtenido por ls -l tiene permisos para esto (drwxr-xr-x), pero no tendrá éxito intentando manipular los permisos de otro usuario como hermano dado que no posee permisos de escritura en su carpeta. No sucederá lo mismo si lo intentamos con el user Root, que tiene permisos absolutos y puede modificar lo que desee. Modificando Permisos con el Sistema Octal El comando chmod puede utilizarse con el denóminado sistema octal en que 8 números (del 0 al 7) representan distintas combinaciones de permisos. Para comprender cómo funciona el sistema octal debemos simplemente memorizar qué permisos da cada número. Veamos las equivalencias: 0 = Ningún permiso (---) 1 = Permiso de ejecución solamente (--x) 2 = Permiso de escritura solamente (-w-) 3 = Permisos de escritura y ejecución (-wx) 4 = Permisos de lectura solamente (r--) 5 = Permisos de lectura y ejecución (r-x) 6 = Permisos de lectura y escritura (rw-) 7 = Permisos de lectura, escritura y ejecución (rwx) Notesé que el 7 es la suma del 1 (--x), 2 (-w-) y 4 (r--), es decir, que se asignan todos los permisos. Apliquemos un ejemplo con el sistema octal. Supongamos que el usuario Root ha creado un directorio llamado /scripts y no desea que ninguno de los usuarios no root pueda listar o acceder a los contenidos de éste. Debido a que ninguno de los users creados (carp y hermano) están en el grupo de root (que lleva como nombre root) la denegación de permisos tendrá que afectar a la clase de usuario others. root@home:/# chmod 770 scripts root@home:/# ls -l [...] drwxrwx--- 2 root root 4096 dic 17 04:48 scripts [...] Como puede observarse, ahora el directorio /scripts tiene rwx para el owner (el user root), rwx para el grupo (grupo root) y ningún permiso (---) para el resto de los mortales (entre los que se encuentran carp, hermano y cualquier futuro usuario que se cree en el sistema). Modificando el Propietario de un Archivo o Directorio A veces sucede que necesitamos que un directorio o fichero esté en poder de un usuario distinto a quien lo creó y dar permisos a others no es la solución correcta dado que estaríamos dándole permisos a todos los usuarios en lugar de a un usuario específico. En Linux y sistemas operativos derivados de Unix, suele utilizarse para estos casos el comando chown que nos permite "pasarle la propiedad" de un archivo o directorio a otro usuario. Veamos un ejemplo en que el user root crea un archivo y luego le pasa la propiedad al user carp. root@home:/# touch archivoparacarp.txt root@home:/# ls -l [...] -rw-r--r-- 1 root root 0 dic 23 01:55 archivoparacarp.txt [...] Ahora bien, el fichero creado tiene los permisos por defecto (rw para el owner y sólo r para otros miembros del grupo y usuarios ajenos al mismo). Supongamos que el root user quiere pasarle la propiedad al user carp: root@home:/# chown carp archivoparacarp.txt root@home:/# ls -l [...] -rw-r--r-- 1 carp root 0 dic 23 01:55 archivoparacarp.txt [...] Los permisos no han cambiado pero sí la propiedad del fichero con el resultado de que ahora el usuario carp es el owner y, por extensión, quien posee permisos Read y Write sobre el .txt creado. Cambiando el Grupo de un Archivo o Directorio Es muy corriente que el escenario que acabamos de describir, en que necesitamos darle privilegios a un usuario sobre algún contenido pero no queremos hacerlo a través de others, se de también en situaciones en que no queremos perder la propiedad de un directorio o contenido. Necesitamos que el user carp tenga todos los permisos sobre un archivo pero no queremos darle la propiedad de éste ni dotarlo con los permisos vía others dado que ésto otorgaría los privilegios que sólo queremos para carp a todos los usuarios del sistema. La solución en estos escenarios llega a través de los grupos (cuya existencia no es un mero capricho) y el comando chgrp que nos permitirá cambiar el grupo de usuarios de un contenido. Supongamos que nuevamente el Root user necesita darle privilegios de lectura y escritura al user carp sobre un archivo específico, pero esta vez lo hará definiendo esos permisos para la clase de user group y luego cambiará a carp el grupo en cuestión (root, dado que es el usuario root quien creará el fichero). Veamos el procedimiento: root@home:/# touch archivoparacarp2.txt root@home:/# ls -l [...] -rw-r--r-- 1 root root 0 dic 23 01:55 archivoparacarp2.txt [...] El usuario root cambia a continuación el grupo al que el archivo pertenece de root a carp y asigna, luego, los permisos deseados al grupo: root@home:/# chgrp carp archivoparacarp2.txt root@home:/# chmod 664 archivoparacarp2.txt root@home:/# ls -l [...] -rw-rw--r-- 1 root carp 0 dic 23 01:55 archivoparacarp2.txt [...] Como podemos apreciar, el grupo ha cambiado y los permisos asignados vía 664 afectarán al user carp que podrá leer y escribir este archivo. El usuario root sigue siendo el owner y carp participa de los privilegios asignados porque el fichero pertenece a root con permisos rw tanto como al grupo carp con los mismos permisos. Esta es una forma de darle control sobre un contenido a un usuario sin exponer el contenido a todos los usuarios ni perder la propiedad del mismo. Conclusiones Como hemos podido comprobar Linux nos brinda herramientas para controlar la privacidad de la información de cada usuario con gran precisión y versatilidad. Esta es, entre otras, una de las características que distinguen a los Sistemas Operativos basados en Unix de aquellos creados por Microsoft y explica en parte el hecho de que a lo largo del tiempo las grandes empresas que necesitan contar con sistemas de información seguros y garantizar una interacción a distintos niveles con los datos hayan escogido Linux u otros sistemas derivados de Unix. Si bien aquí hemos intentado dar cuenta de estas utilidades, el sistema de usuarios en Linux merece un capítulo aparte. Vimos nada más cómo crear un usuario con adduser y nuestro OS dispone de un conjunto de comandos que posibilitan una sencilla administración de usuarios permitiendo llevar a cabo las funcionalidades requeridas para esta tarea. Intentamos, sin embargo, poner el foco en la manipulación de los permisos por encontrar que éstos constituyen una novedad para los usuarios provenientes de Windows. Nos parece que, si bien pueden estar familiarizados en algún punto con las cuentas de usuario, no lo estarán con los Permisos Unix y a más temprano pueda entenderse el modo en que éstos operan mayor será el provecho que podremos obtener de Linux.

Aunque me costará algo de trabajo, no ahondaré aquí en las razones para realizar este cambio. Se asume que quienes llegan a leer este post saben por qué desean abandonar Mysql y -sin apedrear a Oracle, cosa que demandaría sendos artículos- procedemos a explicar brevemente qué es MariaDB y cómo podemos reemplazar nuestras Bases de datos Mysql por éste motor sin complicarnos la vida ni tener que adaptar en nada nuestras consultas y configuraciones. Una mudanza 100% transparente La gente de MariaDB brinda una alternativa altamente compatible a quienes quisieran no depender de Mysql, cuyos destinos son más o menos inciertos desde que Oracle no ha tenido una gestión ejemplar con OpenOffice y pareciera estar en el mismo camino en este caso. Dado que MariaDB es un fork de mysql o, como ellos mismos lo dicen, un "drop-in replacement for MySQL", podemos pasar desde el Mysql que tenemos andando a MariaDB sin darnos cuenta del cambio en lo que a funcionalidad de nuestras bases de datos y aplicaciones refiere. Si bien no es menester aquí ahondar en los beneficios o características de MariaDB, recomendamos la lectura del about en https://mariadb.org/en/about/. Es necesario tomar muy en serio a este fork. Basta mirar la creciente nómina de distribuciones Linux (https://kb.askmonty.org/en/distributions-which-include-mariadb/) que ya lo usan como reemplazo de Mysql (entre las que destacan ArchLinux, OpenSUSE y Gentoo). Instalando MariaDB Vamos a instalar MariaDB en Linux Debian Squeeze con LAMPP. Se trata de un servidor de desarrollo que corre Mysql 5.5 y posee multiples bases de datos en funcionamiento. Debido a que queremos reemplazar transparentemente el motor de base de datos es importante cuidar la compatibilida de la versión de Mysql que tenemos (5.5) con la versión de MariaDB que instalaremos. Tomemos un minuto para estudiar esto en el sitio de MariaDB (https://kb.askmonty.org/en/mariadb-versus-mysql-compatibility/). Comencemos por importar las keys gpg para garantizar la integridad de los paquetes que instalaremos. Estaremos usando la clave CBCB082A1BB943DB tomada de aquí http://pgp.jjim.de/pks/lookup?op=vindex&search=0xCBCB082A1BB943DB carp@server1:~$ su root Ingresamos clave de root root@server1:/# gpg --keyserver keys.gnupg.net --recv-keys CBCB082A1BB943DB Una vez importada la clave, agregamos un repositorio a nuestra lista para poder instalar vía apt. Podemos obtener los repositorios para distintas distribuciones y versiones tanto de estas como del MariaDB a instalar en https://downloads.mariadb.org/mariadb/repositories/. Agregado el repo, actualizamos el gestor de paquetes. root@server1:/# echo "deb http://mirror.aarnet.edu.au/pub/MariaDB/repo/5.5/debian squeeze main" >> /etc/apt/sources.list root@server1:/#echo "deb-src http://mirror.aarnet.edu.au/pub/MariaDB/repo/5.5/debian squeeze main" >> /etc/apt/sources.list root@server1:/# apt-get update Nuestro repositorio ha sido agregado y ya podemos proceder con la instalación de MariaDB 5.5. El proceso desintalará mysql-client y mysql-server (do not panic, every little thing is gonna be allright). El instalador listará las operaciones y pedirá definir una clave de root para MariaDB root@server1:/# apt-get install mariadb-client mariadb-server mariadb-client-5.5 mariadb-server-5.5 mariadb-server-core-5.5 mariadb-client-core-5.5 Finalizada la instalación y habiendo definido nuestra password procedemos a reiniciar mysql y luego nos conectamos a mysql como root para comprobar la versión de MariaDB. root@server1:/# /etc/init.d/mysql restart Stopping MariaDB database server: mysqld. Starting MariaDB database server: mysqld .. Checking for corrupt, not cleanly closed and upgrade needing tables.. root@server1:/# mysql -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or g. Your MariaDB connection id is 113 Server version: 5.5.30-MariaDB-mariadb1~squeeze mariadb.org binary distribution Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. Type 'help;' or 'h' for help. Type 'c' to clear the current input statement. MariaDB [(none)]> show global variables like "version"; Podemos ahora revisar nuestro phpmyadmin así como nuestros sitios para comprobar que todo está tal cual estaba antes

En la medida en que los problemas surgen, busco en Google, resuelvo -las más de las veces- y creo que es una buena idea compartir escribiendo los pasos que segui en cada caso como a mi me hubiera gustado encontrarlos.Se trata -en esta oportunidad- de algo muy sencillo: hemos tocado tanto Mysql que simplemente desearíamos comenzar de cero por lo que necesitamos un clean uninstall de mysql-server para, luego, reinstalar y volver a comenzar.Esto es muy sencillo en Debian Squeeze y supongo que debe serlo en otras distribuciones. No necesitamos explicar que todas las bases de datos del servidor van a perderse. Vamos a desinstalar por completo mysql de suerte que si luego intentamos un mysql -u root -p bash no reconocerá el programa.Vamos a la consola, pero antes una aclaración fundamental. Al desinstalar mysql del modo en que lo haremos, estaremos desinstalando todos los paquetes cuyo nombre comience con mysql (el asterisco es REGEX para todo lo que se llame mysql+cualquier cosa). Es muy importante comprender que muchas aplicaciones no vinculadas a un Lampp hacen uso de algunos paquetes mysql.Un ejemplo: en el Box que uso para trabajar (el único con interface gráfica) corri el comando tal cual se describe abajo y al reiniciar me encontré con que mi KDE había desaparecido y entraba en Gnome sin chances de elegir una sesión KDE en el Login. Por fortuna recuperé mi KDE tal cual lo tenía corriendo como root apt-get install kde-plasma-desktop.Como conclusión la desinstalación de mysql a través de este método es recomendable sólo en el caso de que uno sepa muy bien cuales son las dependencias que se perderán. En lo personal realicé el procedimiento en otros boxes sin GUI sin inconvenientes. carp@server1:~$ su rootingresamos la clave de rootroot@server1:/# apt-get --purge remove mysql* La desinstalación comenzará y al finalizar habremos borrado todo lo relacionado a mysql de nuestro servidor, de suerte que si intentamos un mysql -u root -p nos encontraremos con el fastidioso bash: mysql: no se encontró la orden, esperado en este caso.Luego para reinstalar podemos usar el CD o DVD de la distro o bien agregar a sources.list la fuente del paquete mysql-server. En mi caso agregué deb http://ftp.us.debian.org/debian squeeze main y luego corri root@server1:/# apt-get install mysql* Si esta instrucción arrojara el clásico "E: No se ha podido localizar el paquete mysql" intenten con: root@server1:/# apt-get install mysql-server Y a recomenzar con Mysql!SaludosPublicado originalmente en mi Blog personal: http://www.danieldemichele.com.ar/2011/11/22/desinstalar-mysql-en-debian/

Este va a ser bien cortito pero seguramente de mucha utilidad para quienes recién comienzan a utilizar Linux y han optado por el módico esquema de un Dual Boot para poder elegir en el inicio si van a usar Photoshop o a Linuxear Lo primero con que nos encontramos al instalar, en mi caso Debian Squeeze, e iniciar el sistema es que, si bien durante la instalación de Debian se reconocen otras particiones con NTFS al ingresar éstas o bien no están en /mnt o bien aparecen pero no puede escribirse en ellas.Lograr que al iniciar Linux las particiones Windows aparezcan y puedan escribirse es sencillo y requiere editar el fichero /etc/fstab. Tomemos mi caso:Mi PC tiene 3 HHDD SATA, 2 de 500GB y uno de 360GB en el que tengo un Dual Boot Win7/Debian6. En total, sin contar la partición de Debian tengo 4 Discos y particiones (uno de los discos de 500GB no está particionado y se utiliza para Backups). Es decir que necesitaba poder disponer, utilizar y escribir desde Debian en estas 4 particiones.La solución -como dije- fue muy simple: carp@server:/$ su root Ingresamos pass de rootroot@server:/# pico /etc/fstabAl final del fichero fstab, agregué:/dev/sda2 /mnt/winsys ntfs-3g umask=0,nls=utf8 0 0/dev/sda5 /mnt/windata ntfs-3g umask=0,nls=utf8 0 0/dev/sdb1 /mnt/backup ntfs-3g umask=0,nls=utf8 0 0/dev/sdc1 /mnt/data3 ntfs-3g umask=0,nls=utf8 0 0Salvar (ctrl+o) y salir (ctrl+x) Al reiniciar y entrar a Debian allí estaban mis particiones con permisos de lectura/escritura. Es importante guardar una copia del original cuando trabajaremos sobre ficheros sensibles como lo es fstab (un error allí puede traer un lindo dolor de cabeza al reiniciar). Si bien yo no lo he hecho en los procedimientos aquí detallados, lo hago siempre antes de tocar con cp /etc/fstab / etc/fstab_orig lo cual me daría la posibilidad de restaurar el original en caso de panic!

Trabajar con Servidores Web requiere generalmente disponer de una serie de herramientas con que interactuar con los Boxes y en este capítulo vamos a dedicarnos al viejo y buen FTP (File Transfer Protocol), imprescindible a la hora de transferir o descargar rapidamente archivos desde nuestros Servers.Linux ofrece muchas alternativas a la hora de instalar un ftp-server y hemos optado en este caso por trabajar con ProFTPD debido a que es un servidor ftp robusto y configurarlo con medidas extra de seguridad (TLS) es relativamente sencillo.La necesidad de securizar nuestras transferencias FTP con un protocolo como TLS (Transport Security Layer) reside en que al operar con FTP estamos moviendo a través de internet archivos de texto plano que podrían ser facilmente legibles en caso de que, por ejemplo, trabajemos en una red en que corre un Sniffer. La tarea de TLS será la de garantizar que los datos de conexión al servidor FTP y los paquetes que subamos o bajemos sean encriptados de modo tal que, ante un sniffer u otra herramienta que intercepte nuestra tráfico no corramos el riesgo de exponer información valiosa.Instalando ProFTPDComenzaremos por instalar y configurar este servidor FTP. Al finalizar esta sección tendremos un servidor FTP funcionando sin ninguna clase de securización.Trabajaremos sobre Debian Squeeze y asumimos que hay un Lampp instalado y corriendo (aunque realmente no lo precisaremos) al que deseamos agregarle un servidor FTP con el que cargar contenidos al directorio en que se encuentra nuestro sitio. carp@server1:~$ su root Ingresamos clave de root root@nodo0:/# apt-get install proftpd openssl La instalación preguntará si deseamos correr el server FTP como Standalone (Independiente), o desde inetd. Elegimos Standalone.Una vez terminado el proceso de instalación ya tenemos nuestro servidor ftp instalado y funcionando. Intenta una conexión usando una cuenta no root y conseguirás acceso al home del usuario empleado. Como verás puedes subir niveles hasta / y acceder a archivos de configuración en /etc: el usuario puede explorar todo el servidor y esto es algo que -por razones evidentes- no queremos.Necesitamos poner un jail para que cuando el user carp se conecte, ingrese al listado de /home/carp sin posibilidades de subir de nivel. Esto es muy sencillo de realizar modificando el valor de DefaultRoot en el archivo de configuración de proftpd (/etc/proftpd/proftpd.conf). root@nodo0:/# /etc/init.d/proftpd stopStopping ftp server: proftpd.root@nodo0:/# pico /etc/init.d/proftpd.confBuscamos en el fichero de configuración la línea comentada:# DefaultRoot ~La descomentamos y modificamos de modo que quede:DefaultRoot /var/www carpGuardamos, salimos e Iniciamos ProFTPD nuevamente:root@nodo0:/# /etc/init.d/proftpd start Basicamente hemos descomentado el parámetro que nos permite restringir el acceso vía FTP proporcionando el path al que nuestro user (carp) debe acceder al conectarse seguido del nombre de usuario.Si reiniciamos proftpd e intentamos conectarnos nuevamente con el user carp FTP listará los contenidos de /var/www y no habrá posibilidad de subir niveles: /www es la rama más alta en el árbol de este usuario.Securizando nuestro Servidor FTP con TLSHasta aquí disponemos de un servidor 100% funcional. Ahora nos encargaremos de securizarlo utilizando TLS.Si bien ProFTPD viene con soporte para TLS, tendremos que crear un certificado SSL para poder habilitar esta funcionalidad. Dicho esto, vamos a crear un directorio ssl dentro de /etc/proftpd en que guardaremos nuestro Certificado y Key SSL. root@nodo0:/# mkdir /etc/proftpd/sslroot@nodo0:/# openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem Se nos presenta un aviso y un formulario en que debemos proporcionar datos básicos:Generating a 1024 bit RSA private key.........++++++........................................++++++writing new private key to '/etc/proftpd/ssl/proftpd.key.pem'-----You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) :ARState or Province Name (full name) [Some-State]:Buenos AiresLocality Name (eg, city) []:MerloOrganization Name (eg, company) [Internet Widgits Pty Ltd]:DDMOrganizational Unit Name (eg, section) []:DDMCommon Name (eg, YOUR name) []:DanielEmail Address []:[email protected] root@nodo0:/# No entraremos en detalles acerca de cómo crear Certificados SSL con Openssl, pero sí recomendamos -a quienes quieran conocer un poco más acerca de la creación de certificados self-signed- la lectura de este How To en el sitio de Openssl.Habiendo creado nuestro certificado volvemos sobre el archivo de configuración de ProFTPD para habilitar la funcionalidad de TLS. root@nodo0:/# pico /etc/init.d/proftpd.confBuscamos y descomentamos quitando el #:Include /etc/proftpd/tls.confGuardamos y salimos. A continuación y finalizando, debemos configurar el fichero /etc/proftpd/tls.conf que viene con el paquete proftpd. Debido a que este fichero contiene unas cuantas líneas nos resultará más sencillo eliminar su contenido y reescribir los parametros de configuración para que TLS funcione con nuestro certificado y clave. Manos a la obra: root@nodo0:/# cat /dev/null > /etc/proftpd/tls.confroot@nodo0:/# pico /etc/proftpd/tls.confNos encontraremos con el fichero en blanco y allí escribimos:<IfModule mod_tls.c>TLSEngine onTLSLog /var/log/proftpd/tls.logTLSProtocol SSLv23TLSOptions NoCertRequestTLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pemTLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pemTLSVerifyClient offTLSRequired on</IfModule> Guardamos, salimos y reiniciamos proftpdfroot@nodo0:/# /etc/init.d/proftpd restartStopping ftp server: proftpd.Starting ftp server: proftpd.root@nodo0:/# Y eso es todo! Nuestro Servidor FTP cuenta ahora con la seguridad de transacciones protegidas por un protocolo de encriptación basado en SSL.Conectando con mi FTP ClientPara terminar, hay que aclarar que el hecho de haber implementado TLS sobre FTP implicará realizar un tipo de conexión desde el cliente FTP que utilicemos distinta a la que acostumbramos usar para acceder a una cuenta de FTP sin ninguna clase de securización.La mayoría de los clientes FTP poseen la opción de conectar a FTP con TLS (Este tipo de conexión suele llamarse FTPS también). En el caso de Fillezilla, basta con ingresar los datos como de costumbre con la salvedad de que en cifrado debe elegirse "Requiere FTP Explicito Sobre TLS" en lugar del valor por defecto "Utilizar FTP simple".En caso de no encontrar la opción para realizar conexiones TLS, revisen la documentación del cliente para asegurarse de que éste posee soporte (y si no lo tiene consideren seriamente utilizar otro cliente).Este Post fue publicado originalmente en mi Blog: http://www.danieldemichele.com.ar/2011/12/07/proftpd-configurando-un-ftp-server-con-tls/

¿Qué es la Replicación?La Replicación es un mecanismo mediante el cual los cambios efectuados a una base de datos (MASTER) impactan inmediatamente sobre otra/s (SLAVES) permitiendo poseer contenido sincronizado y distribuído entre varios servidores mysql: ideal para balancear carga entre nodos. Sin embargo, replicar de este modo no constituye un método eficiente para garantizar la integridad de la información ni una solución de Backup dado que un eventual daño a la BD MASTER se replicará inmediatamente a las SLAVES.Este método (MASTER->SLAVE) supone además la limitación de que sólo la Base de Datos Master es suceptible de operaciones INSERT/UPDATE/DELETE, en tanto que la Slave se encuentra limitada a SELECTS. Si bien no es la mejor solución para desarrollar una estrategia de HA veremos cómo implementarla y dejaremos para la próxima edición un modelo de Replicación más efectivo (MASTER-MASTER) a la hora de pensar en Load Balancing y HA.Presentación del EscenarioVamos a explicar cómo implementar un mecanismo de Replicación MASTER-SLAVE entre dos bases de datos Mysql alojadas en dos Servidores Apache2 corriendo Debian Squeeze. Este artículo asume que se poseen dos computadoras en Red corriendo Linux con LAMPP instalado en ambos casos. Presentemos el escenario:Server 1 (Master): 192.168.1.33Server 2 (Slave): 192.168.1.34Base de Datos MYSQL en Server 1: mibase (la base de datos debe tener al menos 1 tabla con datos para poder verificar la replicación)Manos a la Obra: configurando el MASTER (192.168.1.33)Trabajaremos primero en el Servidor MASTER. Vamos a realizar las configuraciones pertinentes al archivo my.cnf y crearemos un usuario mysql con privilegios ALL + REPLICATION. A lo largo de este breve tutorial trabajaremos exclusivamente con una terminal o en modo texto. Esta es una buena práctica dado que la mayoría de las veces realizaremos estas tareas administrativas vía ssh en servidores remotos o bien en boxes que, por cuestiones de rendimiento, no tienen Interface Gráfica.Lo primero que haremos es editar el archivo de configuración de MYSQL que se encuentra en /etc/mysql/my.cnf. Recordemos que para editar estos archivos debemos loguearnos como root. admin@server1:~$ su rootingresamos pass de rootroot@server1:/# pico /etc/mysql/my.cnf Al abrir el fichero nos encontraremos con los parametros que configuran el Motor de Base de Datos Mysql. Buscamos en el archivo la sección con cabecera . Lo primero es encontrar la línea bind-address cuyo valor estará por defecto en 127.0.0.1. Esta línea limita el alcance del Servicio Mysql al Servidor 1 y, dado que necesitaremos comunicarnos con el Servidor 2, la comentamos agregado un # delante de suerte que quedará:#bind-address = 127.0.0.1Si bajamos un poco más en el fichero (siempre dentro de la cabecera ) encontraremos los siguientes valores que estarán comentados con # y deben ser descomentados y configurados del siguiente modo: server-id=1log_bin = /var/log/mysql/mysql-bin.logbinlog_do_db = mibase Guardamos los cambios al fichero my.cnf y luego reiniciamos MYSQL root@server1:/# /etc/init.d/mysql restart Con esto tenemos la configuración lista. Procedemos a la creación de un usuario mysql que será el encargado de tramitar la Replicación. Para mantener los comandos claros digamos que el usuario mysql que crearemos tendrá como nombre daniel y como clave suclave. Procedemos entonces a la creación del usuario ingresando a mysql como root. root@server1:/# mysql -u root -pclave de root mysqlmysql> GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'%' IDENTIFIED BY 'suclave';mysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'%';mysql> FLUSH PRIVILEGES;mysql> USE mibase;mysql> FLUSH TABLES WITH READ LOCK;mysql> SHOW MASTER STATUS; Cada uno de los comandos escritos en la shell de mysql terminan en ; y deben ingresarse de a uno seguidos de la tecla Enter. Terminada esta rutina, el comando SHOW MASTER STATUS nos mostrará una tabla de este tipo:Al finalizar la configuración del Server 2 necesitaremos los datos que aparecen listados en las columnas File y Position de la tabla obtenida por lo que es recomendable guardarlos.Por último quitamos el Read Lock que habíamos puesto a las tablas y salimos de la shell mysql. Hemos terminado la configuración del Server 1 con la Base de Datos MASTER. mysql> UNLOCK TABLES;mysql> QUIT;root@server1:/# Configurando el Server Slave (192.168.1.34)Vamos a comenzar nuevamente por editar el fichero de configuración de MYSQL, ubicado en /etc/mysql/my.cnf.Al igual que en servidor MASTER, comentaremos la línea que limita el alcance del servicio a la interface local (bind-address).Comentada la línea debemos introducir los siguientes cambios bajo la cabecera de modo que el fichero quede así: root@server2:/# pico /etc/mysql/my.cnf#bind-address = 127.0.0.1server-id=2master-host=192.168.1.33master-user=danielmaster-password=suclavemaster-connect-retry=60replicate-do-db=mibaseGuardamos los cambios y reiniciamos Mysql:root@server2:/# /etc/init.d/mysql restart Aquí debemos detenernos un segundo para explicar un posible problema con el que yo me encontré y quizás muchos se ahorren.Hemos, en los ficheros my.cnf de los dos servidores, comentado la línea bind-address = 127.0.0.1 por la evidente razón de que necesitaremos que mysql interactue dentro de la Red local con su box vecino (por ejemplo, le decimos al Slave que su Master está en 192.168.1.33).Ahora bien, MYSQL utiliza el puerto 3306 y ocurre, en algunos casos, que este puerto no se encuentra abierto (ya sea en el Firewall del OS o bien en el Router). Uno puede realmente perder mucho tiempo recibiendo errores de acceso denegado para el usuario mysql creado hasta darse cuenta de que no hay comunicación entre los boxes.Para verificar que el usuario creado (daniel) desde el Server MASTER tiene acceso al SLAVE (es decir, que hay comunicación vía el puerto 3306 entre los 2 equipos) intentaremos loguearnos a mysql en el SLAVE del siguiente modo: root@server2:/# mysql -u daniel -h 192.168.1.33 -pIngresamos la clave suclave Si obtenemos la shell mysql (mysql> entonces estamos listos para continuar. Si, por el contrario, recibimos un error que alude a que el usuario no posee acceso, tendremos que abrir el puerto vía iptables del siguiente modo: root@server2:/# /sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPTroot@server2:/# iptables-save Agregada la regla en el Server 2, reintentamos: root@server2:/# mysql -u daniel -h 192.168.1.33 -pIngresamos la clave suclave Si esto no funcionara, queda agregar al Firewall del Router una Regla LAN TO LAN que permita el tráfico vía el puerto 3306. Este no es un escenario muy común, pero en mi opinión (IMHO) nada se pierde con agregar una regla en el ámbito local para garantizar que el tráfico de box a box fluya por el puerto en cuestión.Como último paso para probar la Replicación tendremos que crear una Base de Datos en el Servidor Slave que lleve el mismo nombre que la MASTER (mibase). Para esto: root@server2:/# mysql -u root -pclave de root mysqlmysql> CREATE DATABASE mibase; mysql> LOAD DATA FROM MASTER; mysql> QUIT; Y ha llegado la hora de revisar la Base de Datos que acabamos de crear en el Servidor SLAVE: una copia exacta de los contenidos de la Base MASTER debería estar ahora en la SLAVE. Hemos replicado los contenidos con la instrucción LOAD DATA FROM MASTER.Nos queda un último y fundamental paso: el de automatizar el proceso de Replicación de modo que los cambios realizados en la Base Master impacten a la Slave al instante y sin intervención de ninguna clase.Para esto, reconectamos a la shell de mysql, detenemos la Base de Datos SLAVE, introducimos los valores que determinarán la configuración automática de la Replicación reemplazando los valores de MASTER_LOG_FILE y MASTER_LOG_POST por los obtenidos en la tabla que arrojó la sentencia SHOW MASTER STATUS en Server MASTER y, por último, volvemos a iniciar la Base SLAVE. root@server2:/# mysql -u root -pclave de root mysqlmysql> SLAVE STOP;mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.33', MASTER_USER='daniel', MASTER_PASSWORD='suclave', MASTER_LOG_FILE='VALOR_OBTENIDO', MASTER_LOG_POS=VALOR_OBTENIDO; mysql> SLAVE START;mysql> QUIT; Ahora nos vamos a la Base Master, realizamos cuantos cambios queramos y constatamos la Replicación inmediata en su par SLAVE. Si se diera el caso de que queremos optimizar rendimiento de Mysql a través de este modelo de Replicación podríamos instruir nuestra aplicación en Server para que Sirviera todos los requests que involucren SELECTS de SLAVE y trabajara con MASTER sólo en los casos en que las operaciones de Alteración de datos son requeridas.Espero poder subir en breve un tutorial similar pero con Réplica MASTER-MASTERSaludos!

1. Nociones básicas de Escalabilidad, Load Balancing y FailoverEn este artículo veremos cómo configurar un Load Balancer con Failover usando software con el fin de Balancear un Web Server. Un Load Balancer es, en escencia, un sistema que recibe peticiones de un cliente, las procesa a partir de algún criterio (algoritmo) y finalmente las envía a alguno de los servidores que las resolverán y responderán.Si ya estás familiarizado con los conceptos de escalabilidad, Load Balancing y Failover quizás quieras saltearte esta parte e ir directo al punto 2, en que comenzaremos a detallar la configuración de nuestro Cluster HA.En esta oportunidad, balancearemos la carga de un Web Server (HTTP), pero los Load Balancers suelen permitir balanceo de diversos servicios tales como smtp, ftp, https, dns, pop3 y otros.Pongamos por ejemplo que nuestro sitio web se encuentra alojado en un dedicado y que debido al alto tráfico el servidor comienza con picos de Server Load que sobrecargan el procesador. Esto, generalmente, tiene el poco feliz final de downtime o una respuesta lenta y nos pone frente al problema y el mundo de la escalabilidad: debemos resolver el alto tráfico de algún modo.Ahora bien, existen dos modos de encarar este problema y conseguir que nuestro Servidor Web soporte el tráfico. En los 2 casos estaríamos "escalando" pero de distinto modo.Escalar verticalmenteTan simple como comprar un dedicado con mayor capacidad (CPU, RAM). Si el tráfico sigue creciendo y el día de mañana el nuevo Server nos queda chico nuevamente compramos uno más grande. Y así ...Escalar horizontalmenteEste método apela a una solución más económica y consiste en agregar un nuevo servidor al servidor saturado de modo de tener 2 servidores web con copias idénticas de nuestro sitio y "repartir" el trabajo que antes realizaba el dedicado original. Un eventual crecimiento del tráfico permitiría agregar uno o más servidores.En materia de escalabilidad, la solución correcta a la hora de responder a tráfico alto y posibilidades de que éste siga creciendo es escalar horizontalmente y es aquí donde los Load Balancers se tornan necesarios dado que una estructura de servidores como la descripta en el modelo de escalabilidad horizontal requiere que delante de los 2 o más servidores webs de que disponemos, exista un sistema que capture las peticiones de los visitantes y las envíe a uno u otro servidor, repartiendo de este modo el trabajo y la carga.Decimos que la escalabilidad horizontal es el método adecuado porque escalar verticalmente tiene un límite (en algún punto llegaremos a la instancia en que compramos el Servidor más potente que nuestro Datacenter pueda ofrecernos, habremos invertido muchísimo dinero en Servidores y las migraciones de la aplicación a un server más grande sin downtime y -finalmente- acabaremos pensando en escalar horizontalmente).Por otro lado, escalar horizontalmente es económico, dado que se utilizan muchos boxes de bajo costo. Agregar un nuevo Box detrás del Load Balancer es tarea de minutos y no supone downtime de ninguna clase (al menos si las cosas salen bien). Se elimina además un problema fundamental en el mundo de la alta disponibilidad: el SPF o Single Point of Failure debido a que si un Box "se muere" el Balaceador detectará su estado (Failover) y seguirá enviando las peticiones de los clientes a los otros: tendremos tiempo de arreglarlo o reemplazarlo de un modo transparente para nuestros visitantes.Las ventajas de escalar de este modo no terminan aquí (otra muy fuerte es el Global Load Balancing, que permite detectar la ubicación geográfica de nuestro visitante y resolver sus peticiones con el Servidor más cercano a él). En resumen, explicar las virtudes de escalar horizontalmente requeriría un extenso artículo dedicado al tema. Nos bastará con saber que éste es el esquema elegido por Google, Facebook y, en línea generales, todos los sitios que deben resolver millones de Requests por segundo día a día.2. Comenzando con nuestro Load BalancerAntes de comenzar a configurar nuestro LB, debemos introducir -aunque sea, brevemente- una distinción acerca de estos sistemas ubicados al frente de nuestros servidores. Existen 2 tipos de Load Balancers. Estos son:1. Hardware Load Balancer 2. Software Load BalancerLoad Balance con Hardware supone utilizar equipos de red diseñados específicamente para realizar Balanceo de Carga. Se trata en todos los casos de dispositivos con un costo bastante alto. Un ejemplo típico es el conocido F5 Big Ip de F5 Networks, aunque existen muchas empresas que fabrican éste tipo de componentes de Networking.Por otro lado, hacer Load Balancing con Software supone contar con Boxes dedicados exclusivamente a esta tarea. Estos boxes corren Linux y sobre ellos instalamos algun software que se encargará de realizar el balanceo.Existen diversas soluciones para hacer Load Balancing con Software. La más conocida es, quizás, Linux Virtual Server (LVS), pero hemos optado en este caso por Haproxy, dado que es una solución tan robusta como sencilla de poner a andar, representando la elección ideal para introducirnos en el mundo del Load Balancing.2.1 Nuestro escenarioVisto y considerando que balancearemos un Servidor Web que corre una aplicación PHP/MYSQL necesitamos como mínimo disponer de 3 equipos con Linux (Debian Squeeze, en nuestro caso). Uno de los equipos será destinado al Balanceo y los otros dos serán los servidores lampp detrás de éste. Necesitaremos además crear una IP virtual en el balanceador, a la que direccionaremos todo el tráfico.Aquí están los valores con que trabajaremos- Nodo1: Load Balancer - Debian Squeeze + Haproxy (192.168.1.31)- Nodo2: Server HTTP - Debian Squeeze + LAMPP (192.168.1.32)- Nodo3: Server HTTP - Debian Squeeze + LAMPP (192.168.1.33)- IP Virtual: 192.168.1.20- Dominio virtual: www.sitio.dev3 notas sobre este entorno1. Es muy importante que nuestras interfaces de Networking en cada box estén configuradas estáticamente y no vía DHCP. Si éstas obtienen su IP vía DHCP es hora de setearlas a static. Hacer esto es muy simple y pueden seguir éste artículo para llevar esta tarea a cabo.2. Debido a que estamos trabajando en una Red local no usaremos Bind9 para resolver nombres de dominios. Nos limitaremos a editar el archivo hosts del Box Balanceador para que un nombre de dominio ficticio www.sitio.dev apunte a la IP virtual (192.168.1.20).3. Al lector atento no se le habrá escapado que este entorno tiene un SPF a nivel del Load Balancer: si la máquina corriendo Linux y Haproxy se cae por alguna razón nuestro sitio alojado en los 2 Servidores no responderá cuando ingresemos www.sitio.dev en nuestro navegador. Nos hemos tomado la licencia de trabajar con este SPF para la redacción de este artículo, pero si quisieramos configurar un Cluster de alta disponibilidad con Failover en producción lo ideal sería disponer de un segundo Box pasivo balanceando que tomara la tarea del primero ante una eventual falla (arquitectura active/passive). Estos 2 Load Balancers podrían utilizar heartbeat para conocer su estado constantemente de modo que ante una eventual falla en el Load Balancer 1 la IP Virtual resolviera al Load Balancer 2.3. Configurando la IP Virtual (192.168.1.20) y preparando los servidores webVamos a editar nuestro fichero /etc/network/interfaces en nodo1 (el Load Balancer) para crear una IP Virtual. carp@nodo1:/$ su rootContraseña: Ingresamos clave Rootroot@nodo1:/# pico /etc/network/interfacesDebajo de la declaración estática de la Ip de este Box, agregamos:# Load Balancer VIPauto eth0:1iface eth0:1 inet static address 192.168.1.20 gateway 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255salvamos (ctrl+o), salimos (ctrl+x) y reiniciamos la redroot@nodo1:/# /etc/init.d/networking restartReconfiguring network interfaces...done.root@nodo1:/# Podemos comprobar la creación de nuestra VIP con ifconfigroot@nodo1:/# ifconfig[...]eth0:1 Link encap:Ethernet HWaddr 00:1d:60:d9:03:9a inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1[...] Creada nuestra VIP, editaremos hosts para apuntar el dominio www.sitio.dev a élla. root@nodo1:/# pico /etc/hostsAgregamos debajo de los valores del fichero:192.168.1.20 sitio.dev www.sitio.devsalvamos (ctrl+o) y salimos (ctrl+x) Recordamos que por tratarse de una configuración local no utilizamos (aunque podríamos) Bind9 para resolver dominios. Si así lo hicieramos deberíamos registrar la entrada www como CNAME en la zona correspondiente. Aquí nos limitamos a controlar el dominio ficticio desder hosts y lo repetimos con y sin las www para que éste sea accesible de los 2 modos.Ya tenemos nuestra VIP configurada en nodo1 y el dominio www.sitio.dev apuntando a ella: estamos listos para comenzar con Haproxy, pero antes -siempre resta algo- tendremos que realizar una modificación en el modo en que nuestros 2 servidores Lampp (192.168.1.32/33) almacenarán los logs.Haproxy funcionará como un proxy transparente delante de nuestros servidores web y es de fundamental importancia que los configuremos para que al hacer logging lo hagan con las IPS de nuestros visitantes y no con la del Balanceador (de otro modo todos los request en access y error.log tendrán como IP 192.168.1.20).Para evitar esto ingresamos a cada Box -por lo general a través de ssh- y buscamos en el fichero apache2.conf (en mi caso, las últimas líneas del archivo). Al llegar a la parte en que se definen los Logs encontraremos una explicación comentada de lo que necesitamos cambiar.Vamos con el primer Servidor Web (nodo2 : 192.168.1.32) root@nodo1:/# ssh 192.168.1.32Ingresamos clave root del Box nodo2:root@nodo2:/# pico /etc/apache2/apache2.confBajamos hasta el final del fichero y encontraremos:LogFormat "%v:%p %h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combinedLogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combinedLogFormat "%h %l %u %t "%r" %>s %O" commonLogFormat "%{Referer}i -> %U" refererLogFormat "%{User-agent}i" agentTal cual se explica arriba de esta sección como comentario necesitamos intrudoducir este cambio en la línea 2:LogFormat "%v:%p %h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combinedLogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combinedLogFormat "%h %l %u %t "%r" %>s %O" commonLogFormat "%{Referer}i -> %U" refererLogFormat "%{User-agent}i" agentsalvamos (ctrl+o) y salimos (ctrl+x) Las modificaciones no terminan aquí. El mecanismo de Failover de nuestro software de Balanceo (Haproxy) consiste en enviar requests cada x cantidad de segundos (este valor es configurable, como veremos más adelante) a cada Box para saber si éste se encuentra o no disponible. Para esto, se suele crear un fichero .txt vacío en cada box que Haproxy solicitará para conocer su estado. Si Haproxy obtiene una respuesta positiva (OK 200) entonces el servidor está funcional. Si por el contrario el Request al fichero .txt no es respondido Haproxy no enviará más solicitudes a ese servidor y dirigirá todo el tráfico al otro/s.Ahora bien, necesitamos decirle a nuestros servidores que no computen estas solicitudes ni la logueen, debido a que esto aumentaría drásticamente el tamaño de nuestros logs. Para lograrlo, editaremos el fichero de cofiguración de VirtualHosts en cada uno de los Boxes indicando explicitamente que toda solicitud del archivo test.txt (así se llamará el archivo que aún no creamos) no debe ser incluída en los logs. Seguimos con la sesión ssh en 192.168.1.32root@nodo2:/# pico /etc/apache2/sites-enabled/www.sitio.devEste fichero es copia de 000-default (el archivo que Apache2 trae por defecto) y en él debemos buscar la sección Log Files y modificarla de modo que esto: # Log filesCustomLog /var/log/apache2/access.log combin quede así: # Log filesSetEnvIf Request_URI "^/test.txt$" dontlogCustomLog /var/log/apache2/access.log combined env=!dontlog salvamos (ctrl+o), salimos de nano (ctrl+x) y finalmente cerramos la sesión ssh con exit Ingresamos al segundo servidor web vía ssh (nodo3 : 192.168.1.33) y repetimos lo hecho en los ficheros /etc/apache2/apache2.conf y /etc/apache2/sites-enabled/www.sitio.dev.Una vez que hemos realizado estas modificaciones en ambos servidores, nos reconectamos vía ssh y creamos el archivo test.txt vacío en cada uno en el nivel en que nuestro sitio se encuentra (en cada box corremos touch /var/www/test.txt).4. Instalando y configurando HaproxyAl fin llegamos al punto en que instalamos el software con que realizaremos Load Balancing. Si bien el orden en que estos pasos se han llevado a cabo (preparar los servidores web antes de instalar Haproxy) no tienen por qué transitarse de este modo, es recomendable siempre "preparar" nuestros boxes para el software antes de instalarlo. De esta forma, luego podemos dedicarnos pura y exclusivamente a la configuración del mismo olvidando el resto. root@nodo1:/$ su rootContraseña: Ingresamos clave Rootroot@nodo1:/# apt-get install haproxy Una vez instalado Haproxy (link al paquete por las dudas) procedemos a configurarlo. Debido a que este fichero trae consigo mucha información que no utilizaremos, creamos una copia del original y luego borramos su contenido para poder ingresar nuestra configuración desde 0. oot@nodo1:/$ cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy_orig.cfgroot@nodo1:/# cat /dev/null > /etc/haproxy/haproxy.cfgroot@nodo1:/# pico /etc/haproxy/haproxy.cfg Ingresamos al fichero en blanco y en él introducimos: global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 4096 user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000listen lbservers 192.168.1.20:80 mode http stats enable stats auth carp:miclave balance roundrobin cookie uid prefix option httpclose option forwardfor option httpchk HEAD /test.txt HTTP/1.0 server nodo2 192.168.1.32:80 cookie A check server nodo3 192.168.1.33:80 cookie B checkGuardamos (ctrl+o) y salimos (ctrl+x) Hemos definido en la sección listen la ip virtual a que el Balanceador responderá y el puerto (que por ser Balanceo HTTP es 80). Definimos además un usuario y clave para las stats (que nos permitirán ver el estado de nuestro farm de servers) y optamos por el algoritmo Round Robin para balancear la carga. Como todo buen balanceador, Haproxy permite otros métodos para balancear que no veremos aquí pero es recomendable conocer. Además, definimos la cookie con nombre uid (que de hecho se crea en nuestra aplicación cuando un usuario se conecta con su cuenta) como parámetro para fijar sticky sessions (esto significa que una vez el usuario inicia sesión el Balanceador lo mantendrá en el Box en que se logueó de modo de conservar los valores de la sesión que no se encuentran en otros boxes). Finalmente indicamos el nombre del fichero (test.txt) que le dirá al balanceador si los servidores se encuentran o no usables y, por último, listamos los 2 boxes con lampp hacia los cuales deberán dirigirse los Requests.Ahora vamos a agregar Haproxy a init de modo que se cargue al bootear linux. Esto se realiza seteando ENABLED=1 en /etc/default/haproxy root@nodo1:/# pico /etc/default/haproxyCambiamos ENABLED=0 por ENABLED=1Guardamos (ctrl+o) y salimos (ctrl+x) 5. Finalizando la configuración y probando nuestro BalanceadorSólo un paso nos separa de ingresar www.sitio.dev en nuestro navegador y obtener el sitio web de alguno de los 2 servidores que lo alojan. Debemos agregar al archivo /etc/sysctl.conf la variable net.ipv4.ip_nonlocal_bind con valor 1 para que el kernel permita a nuestras aplicaciones (Haproxy) utilizar una IP que no está asociada a ningún dispositivo (nuestra vip, que no posee un placa). Ingresamos al fichero de configuración y agregamos al final la siguiente línea: root@nodo1:/# pico /etc/sysctl.confEn el final agregamos:net.ipv4.ip_nonlocal_bind=1Guardamos (ctrl+o) y salimos (ctrl+x) Una vez reiniciemos el Load Balancer la configuración que acabamos de agregar será cargada. Para evitarnos un reboot innecesario la cargaremos con el comando: root@nodo1:/# sysctl -pY al fin arrancamos Haproxyroot@nodo1:/# /etc/init.d/haproxy startStarting haproxy: haproxy.root@nodo1:/ Si Haproxy ha comenzado sin problemas y los servidores web nodo2 y nodo3 están corriendo Lampp sin inconvenientes tendríamos que obtener el sitio que alojamos en ellos al ingresar en un navegador (en mi caso el Box con Haproxy tiene GUI y navego desde ahí) www.sitio.devEs una buena idea agregar al body del index.php de ambos sitios algo como "nodo2" y "nodo3" en los respectivos servidores de modo de poder cargar la página y saber a qué box envió la petición Haproxy.Podemos ver el estado de nuestro cluster de servidores ingresando a: http://192.168.1.20/haproxy?stats (les pedirá el user y pass que han definido en /etc/haproxy/haproxy.cfg, sección listen directiva stats.Pueden probar el failover deteniendo uno de los 2 servers para verificar que el sitio seguirá mostrandosé desde el otro y ver en el panel de stats de Haproxy como el server detenido aparece en rojo.6. Consideraciones finalesHaproxy es software poderoso a la hora de realizar Load Balancing con Failover y, como hemos visto, configurarlo no nos ha representado mayores dificultades. Está claro que hemos realizado una configuración básica y seguramente podría mejorarse en varios aspectos. Hemos decidido, simplemente, "ponerlo a andar" como primer paso (esto no es poco). Una vez funcionando pueden estudiar en profundidad el software y tweakearlo como les guste.Aquí hemos asumido que los 2 sitios webs php/msyql alojados en los servers webs detrás del LB, ya han resuelto la sincronización de sus contenidos. Este no es un tema menor y hemos, con anterioridad, cubierto posibles soluciones tanto para sincronizar ficheros como para tener las bases de datos mysql en idéntico estado.

Hace un tiempo escribi un artículo explicando cómo instrumentar Replicación Master-Slave en Mysql para 2 boxes Debian Squeeze y prometi regresar sobre el tema de la Replicación con formato Master-Master. Este artículo viene a demostrar que soy un hombre de palabra =P.Antes de comenzar con el tutorial, considero importante dedicar algunas palabras a la Replicación de datos en Mysql. Recomiendo, además, la lectura del anterior artículo ya que gran parte de lo que veremos aquí fue escrito en él desde que Mysql no tiene una solución específica para Replicar Master-Master y arribamos a este modelo duplicando el trabajo realizado al replicar Master-Slave: es decir, creamos replicacion de master (box1) a slave (box2) y luego repetimos el proceso de master (box2) a slave (box1) de suerte que arribamos -en este caso- a una interface con 2 bases de datos sobre las cuales se pueden realizar tareas INSERT/UPDATE/DELETE, etc que impactarán de inmediato en la contigua.La replicación supone un mecanismo para mantener contenidos alojados en Bases de Datos en sincronía y es, por lo tanto, una estrategia de valor a la hora de escalar. Mysql ofrece la posibilidad de Replicar de una Base de Datos llamada Master a otra Slave. Este modelo, como comentamos en el artículo en que desarrollamos dicha metodología, tiene sus limitaciones y sus beneficios. Las limitaciones se dan en el campo de la funcionalidad de un Slave, que sólo permite operaciones de lectura (SELECT) dejando los writes a cargo del Master. Sin embargo, es bien sabido que en sitios de alto tráfico un alto porcentaje de la interacción con la Base de datos es de tipo lectura: los usuarios se pasean por nuestro sitio y eventualmente escriben la Base de Datos.Es así que tener Servidores de Bases de Datos que sólo permitan lectura puede ser una buena estrategia dado que se podría, por ejemplo, direccionar todo el tráfico de usuarios no conectados a esos servidores liberando a los servidores encargados de escribir en Base de Datos del groso del tráfico. Recordemos que un Master puede tener tantos Slaves como podamos colocarle.Claro está que con el tráfico llegará la necesidad de poder responder a interacciones write con la Base de Datos lo cual supondrá poseer mas de una BD en que puedan realizarse INSERTS/UPDATES/DELETES. Si bien Mysql no otorga una solución específica en materia de Replicación para sincronizar Bases de Datos Write, ésto puede realizarse muy facilmente con una vuelta de tuerca a la Replicación Master-Slave. Con el tiempo y el tráfico creciente nos encontraremos con una arquitectura de BDS Write sincronizadas que a su vez tendrán Slaves para lectura. Las posibilidades para hacer HA escalando horizontalmente son varias y la Replicación en Mysql es uno de varios métodos disponibles.Dichas estas palabras, comencemos con el armado de nuestra arquitectura MASTER-MASTERNuestro EscenarioPara este tutorial usaremos 2 boxes con Lampp instalados sobre Debian Squeeze. Estos son los valores con que trabajaremos:Box Lampp 1 (server1) = 192.168.1.31Box Lampp 2 (server2) = 192.168.1.32Base de datos instalada en ambos servers: blog (la BD de un WordPress)Usuario Mysql = danielClave Mysql = demicheleAsumimos Lampp funcionando con phpmyadmin instalado para disponer de una interface gráfica con que comprobar la replicación así como la base de datos a replicar instalada en los 2 servidores en estado idéntico.Configuración Box 1 (192.168.1.31)Comenzaremos con el primer Box modificando el archivo de configuración de mysql ubicado en /etc/mysql/my.cnf. Mi experiencia con replicación me ha enseñado que lo mejor es empezar por poner a andar un Master-Slave y, una vez que éste funciona, realizar el proceso inverso en el Box 2. Internet está plagada de tutoriales en que se muestran los ficheros my.cnf de los boxes involucrados y las sentencias cruzadas de GRANT REPLICATION SLAVE. Lo cierto es que, si uno copia y pega los contenidos de los archivos modificando los valores y corre los GRANT REPLICATION SLAVE, luego la replicación muy posiblemente no funcionará: nos encontraremos en Google buscando por qué obtenemos Slave_IO_Running: No con SHOW SLAVE STATUSG;Recordemos: la replicación Master-Master es en realidad replicación Master-Slave en 2 sentidos, por lo que comenzar logrando Master-Slave es tener la mitad del trabajo resuelto.Vamos a la consola: carp@server1:~$ su rootingresamos password de rootroot@server1:/# pico /etc/mysql/my.cnf En el archivo my.cnf comenzaremos por quitar la restricción a localhost comentando la línea bind-address = 127.0.0.1 que limita el alcance del servicio a la interface local. Vamos a comentar esta línea con # de modo que quede:#bind-address = 127.0.0.1Bajamos un poco más en el archivo dentro de la cabecera hasta llegar a la sección Logging and Replication y buscamos la línea comentada #server-id = 1. Allí modificamos como sigue: server-id = 1log_bin = /var/log/mysql/mysql-bin.logbinlog_do_db = blogsalvamos los cambios y reiniciamos mysqlroot@server1:/# /etc/init.d/mysql restart Hasta aquí hemos identificado a este servidor con id 1, indicado dónde se encuentra el log del mismo y definido la Base de Datos que nos interesa Replicar hacia el Box 2.A continuación debemos asignar al usuario mysql (daniel) permisos de Replicación en el Box 2. Volvemos a la consola: root@server1:/# mysql -u root -pclave de root mysqlmysql> GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'192.168.1.32' IDENTIFIED BY 'demichele';mysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'192.168.1.32';mysql> FLUSH PRIVILEGES;mysql> USE blog;mysql> FLUSH TABLES WITH READ LOCK;mysql> SHOW MASTER STATUS; Obtendremos una tabla como la siguiente. Es recomendable anotar los valores de File y Position dado que los utilizaremos al final del tutorial para sincronizar los 2 Boxes a partir de la posición de los Logs.Salimos del prompt de mysql quitando el lock a las tablas mysql> UNLOCK TABLES;mysql> QUIT;root@server1:/# Pasamos al Box 2 (192.168.1.32)Continuaremos con los pasos del primer tutorial debido a que estamos intentando realizar Replicación Master-Slave como primer paso. Encontraremos, sin embargo, algo nuevo en la configuración de my.cnf del Box 2 que luego repetiremos en el Box 1: el uso de auto_increment_increment y auto_increment_offset, de vital importancia para el correcto funcionamiento de la Replicación Master-Master.Vamos a la consola del Box 2 a editar la sección Logging and Replication dentro del header : root@server2:/# pico /etc/mysql/my.cnf#bind-address = 127.0.0.1server-id = 2master-host = 192.168.1.31master-user= danielmaster-password= demichelemaster-connect-retry= 60auto_increment_increment = 2auto_increment_offset = 2binlog_do_db = blogbinlog_ignore_db = base_que_no_quiero_afectarGuardamos los cambios y reiniciamos Mysql:root@server2:/# /etc/init.d/mysql restart Aquí nos encontramos con una primera novedad respecto al tutorial de Replicación Master-Slave. Esta consiste en la necesidad de resolver el escenario para campos autoincrement. Supongamos que tenemos 2 Boxes que pueden escribir vía INSERT y manejan un alto tráfico al punto en que se solicitan 2 INSERTS al mismo tiempo en una tabla con autoincrement. El box que primero reciba el INSERT ocupará el próximo índice disponible y deberá comunicarle al otro/s que la posición está tomada y el incremento debe continuar a partir del valor asignado. Esta "comunicación" no será inmediata dado que siempre existe Lag entre los boxes. Con esto nos hacemos una idea del problema al que nos enfrentamos:- el box 1 recibe la orden de insert al mismo tiempo que el box 2- el próximo índice es -digamos- 1000- el box 1 escribe la Base de datos usando el índice y comunica al box 2 que continue a partir del 1001 - pero cuando la sincronización llega al Box 2, éste ya ha escrito su base de datos utilizando el índice 1000- al llegar la sincronización nos encontramos con un DUPLICATE KEY ERRORLos parametros auto_increment_increment y auto_increment_offset configurados debidamente en cada Box nos salvarán de este problema mediante un mecanismo extremadamente intuitivo: el primero seteado en 2 con offset de 2 tramitará los INSERTS en tablas con AI tomando el próximo índice disponible (ejemplo 14) y escribiendo 16 mientras que asignaremos al otro box un offset de 1 de modo que autoincremente naturalmente. En sintesis, el Lag entre boxes deja de importar debido a que cada Base de Datos posee un criterio para tomar índices que evitará la colisión. Más información sobre estos parametros puede ser encontrar en el sitio de Mysql.Comenzando a trabajar la Replicación BidireccionalHasta aquí hemos configurado my.cnf en el Box 1, creado una cuenta de usuario mysql (daniel) con privilegio de Replicar Slave desde el Box 1 en el Box 2 y, por último, configuramos my.cnf del Box 2 para indicarle quien era su Master y proporcionar la información necesaria.Lo que haremos ahora es darle a la cuenta mysql daniel privilegio para hacer Replication Slave pero desde el Box 2 hacia el Box 1 y, finalmente, editaremos my.cnf del Box 1 para decirle que es Slave del Box 2. En pocas palabras: repetiremos lo hecho hasta aquí pero en sentido inverso.En la consola del Box 2 (192.168.1.32) root@server2:/# mysql -u root -pclave de root mysqlmysql> GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'192.168.1.31' IDENTIFIED BY 'demichele';mysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'192.168.1.31';mysql> FLUSH PRIVILEGES;mysql> USE blog;mysql> FLUSH TABLES WITH READ LOCK;mysql> SHOW MASTER STATUS Obtendremos un cuadro simil el anterior. Anotemos los valores de File y Position para el Box 2 (los que anotamos antes pertenecían al Box 1). Tenemos 2 cuentas mysql con el user daniel cruzadas que le permiten Replicar a los slave definidos. Ha llegado el momento de convertir a nuestro Master (192.168.1.31) en un Slave de 192.168.1.32.Transformando al Master 1 en SlaveVolveremos a editar my.cnf de Server 1 para darle las mismas instrucciones que le hemos dado en Server 2: root@server1:/# pico /etc/mysql/my.cnf#bind-address = 127.0.0.1server-id = 1master-host = 192.168.1.32master-user= danielmaster-password= demichelemaster-connect-retry= 60auto_increment_increment = 1auto_increment_offset = 2binlog_do_db = blogbinlog_ignore_db = base_que_no_quiero_afectarGuardamos los cambios y reiniciamos mysqlroot@server1:/# /etc/init.d/mysql restart Con esto, hemos basicamente creado una arquitectura circular (la topología de la replicación Master-Master es, de hecho, circular). Le decimos al Box 1 que tiene server id 1 y debe trabajar con determinada base de datos. Creamos una cuenta mysql desde el Box 1 en que le damos a un usuario permisos para Replicar en un Slave del Box 2. Le decimos al Box 2 (editando my.cnf) donde está su Master (192.168.1.31). Luego repetimos toda la operación en sentido inverso cuidando que los valores de auto_increment_increment y offset estén debidamente seteados. El resultado: los boxes interactúan como Master y Slave entre sí.Sincronizando los BoxesAhora debemos sincronizar los boxes de modo que cada Servidor sepa a partir de qué log mysql trabajar y desde qué posición comenzar (esta es la información que obtuvimos en las tablas al arrojar la sentencia SQL SHOW MASTER STATUS).En el box 1 (192.168.1.31) ingresamos a mysql como root: root@server1:/# mysql -u root -pIngresamos clave de root mysqlmysql> SLAVE STOP;mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.32', MASTER_USER='daniel', MASTER_PASSWORD='demichele', MASTER_LOG_FILE='VALOR_OBTENIDO_EN_BOX2', MASTER_LOG_POS=VALOR_OBTENIDO_EN_BOX2;mysql> SLAVE START;mysql> QUIT; En el Box 2 (192.168.1.32): root@server2:/# mysql -u root -pIngresamos clave de root mysqlmysql> SLAVE STOP;mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.31', MASTER_USER='daniel', MASTER_PASSWORD='demichele', MASTER_LOG_FILE='VALOR_OBTENIDO_EN_BOX1', MASTER_LOG_POS=VALOR_OBTENIDO_EN_BOX1;mysql> SLAVE START;mysql> QUIT; Por último reiniciamos mysql en ambos boxes vía /etc/init.d/mysql restart y podemos probar en cada box si la replicación está funcionando ingresando como root mysql con: root@server1:/# mysql -u root -pIngresamos clave de root mysqlmysql> SLAVE START;mysql> SHOW SLAVE STARTG De la información del SLAVE nos interesa que los valores Slave_IO_Running y Slave_SQL_Running estén en YES en ambos casos. Si todo está ok podemos probar la Replicación ingresando al phpmyadmin de uno de los Servers para agregar un valor y verificar que éste se haya replicado en la BD del otro Server.Lo que los tutoriales nunca te explicanEn mi camino para lograr una buena Replicación Master-Master he leído y probado muchas cosas. El inglés no es -por fortuna- un problema para mi ya que conozco el idioma bastante bien. Este tutorial, al igual que otros que he escrito y seguiré escribiendo es largo. Debo confesar que nada me gusta más cuando ando buscando cómo hacer algo que un tutorial en que se limitan a darme los comandos a utilizar para obtener lo que busco. Sin embargo, algunas cuestiones que revisten una complejidad media/alta como la Replicación merecen una explicación detallada de qué se hace y por qué se hace.A continuación voy a listar algunas posibles causas por las cuales la replicación suele no funcionar y que no he leído en ningún lado.1) La cuenta de usuario mysql (daniel) a la que le asignamos permisos para Replicar no es el usuario utilizado para conectar a mysql ni tiene permisos en local.Esto es tan simple como suena: si estamos usando un user y pass mysql que ya existian y poseían permisos para trabajar con el Blog o Sitio web, entonces usaremos esa misma información cuando hagamos GRANT REPLICATION SLAVE. Lo cierto es que muchas veces cuando intentamos poner a andar replicación le damos GRANT a un usuario que no existe, creandoló en el acto y luego nos encontramos con que el sitio anda bien pero no hay replicación (ni la habrá dado que el usuario al que se le asignó el privilegio de replicar no es el que se está utilizando para interactuar con la BD).Otra cosa común es que al correr la sentencia mysql GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'192.168.1.32' IDENTIFIED BY 'demichele', como hemos hecho en este ejemplo estamos otorgando privilegios a un usuario cuyo ámbito es el otro Box y no el local. Una buena forma de saber si estamos haciendo las cosas bien es intentar loguearse a mysql y phpmyadmin del Box 1 con el usuario en cuestión. Si el usuario y clave no existían, luego de haberlo creado habremos agregado el User Daniel con Host 192.168.1.32 estando en el Box 1 (192.168.1.31).Para resolver este inconveniente comenzamos por verificarlo. Nos logueamos a mysql como root y corremos SELECT User,Host FROM mysql.user; Mysql responderá con una tabla en que se listarán los Usuarios y Hosts en que tienen incumbencia. Si la combinación de User: Daniel Host: localhost no se encuentra, entonces debemos crearla para poder operar en cada box con este nuevo usuario (porque el usuario debe tener los privilegios necesarios para conectarse a la aplicación en localhost y, además, los agregados para Replicar Slave en Box con que se conecta).Agregar el usuario a localhost es tan simple como: root@server1:/# mysql -u root -pclave de root mysqlmysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'localhost';mysql> FLUSH PRIVILEGES;mysql> QUIT; Realizada esta operación el usuario tiene ALL PRIVILEGES en localhost + REPLICATION SLAVE y ALL PRIVILEGES en el server remoto. Esta operación debe ser realizada en ambos boxes2) No hay comunicación entre los servidores porque el puerto 3306 está cerrado en el Firewall.Comentamos la línea bind-address en los ficheros my.cnf de cada servidor para permitir a mysql trabajar con otras máquinas en la red (o fuera de ella). Sin embargo, esto puede no ser suficiente y a veces necesitaremos abrir el puerto con iptables. Diagnosticar la comunicación entre boxes es muy sencillo: tras haberle dado GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'192.168.1.32'; desde el Box 1, lo siguiente debería ser posible: root@server1:/# mysql -u daniel -h 192.168.1.32 -pIngresamos la clave demichel Si obtenemos el prompt mysql tenemos conectividad. Si en cambio obtenemos un mensaje del tipo ERROR 1130 (HY000): Host 'server1' is not allowed to connect to this MySQL server tendremos que abrir el puerto en el Firewall del siguiente modo: root@server1:/# /sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPTroot@server1:/# iptables-save 3) GRANT ¿a quién y sobre qué?Muchos tutoriales sobre Replicación se despachan a la hora de otorgar privilegios para Replicar Slave con sentencias del tipo:GRANT REPLICATION SLAVE ON *.* TO 'user'@'%' IDENTIFIED BY 'clave';Esto se leería -con un poco de humor- más o menos así: "Dale permisos para replicar slave al user en todas las bases de datos en todos los servidores". En este tutorial hemos utilizado la expresión *.* porque sólo poseemos una base de Datos con que trabajaremos. Contamos además con las bases de datos que mysql y phpmyadmin ha instalado pero optamos por excluirlas en los ficheros my.cnf haciendo uso de binlog_ignore_db que puede utilizarse tantas veces como sea preciso para no incluir en la Replica algunas base de datos.Si estuvieramos en un entorno en que trabajamos con VirtualHosts y contamos con una cantidad considerable de Bases de Datos, asignarle a un usuario permisos para Replicar Slave en todas ellas sería una mala idea. Es así que una sentencia de esta clase se adaptaría mejor:GRANT REPLICATION SLAVE ON mibasededatos TO 'user'@'%' IDENTIFIED BY 'clave';Por último el comodín % es también innecesario desde que uno puede o bien querer apuntar a un Host remoro como lo hemos hecho, o bien a localhost. Nuevamente una sentencia más discreta:GRANT ALL ON mibasededatos TO 'user'@'localhost' IDENTIFIED BY 'clave';O bien definir la IP del server destino, como lo hemos hecho aquí.Eso es todo por ahora, la Replicación es un tema que da para mucho y éste -con seguridad- no será el último capitulo.Artículo publicado originalmente en mi Blog: http://www.danieldemichele.com.ar/2011/11/25/replicacion-master-master-en-mysql/