Building a load-balancing MySQL proxy with TrafficScript

creado por Owen Garrett en 22-feb-2013 9:16, modificado por ltima vez por Owen Garrett en 22-feb-2013 9:16 Versin 1

When you need to scale out your MySQL database, replication is a good way to proceed. Database writes (UPDATEs) go to a 'master' server and are replicated across a set of 'slave' servers. Reads (SELECTs) are load-balanced across the slaves.

Overview
MySQL's replication documentation describes how to configure replication:

MySQL Replication

A quick solution...
If you can modify your MySQL client application to direct 'Write' (i.e. 'UPDATE') connections to one IP address/port and 'Read' (i.e. 'SELECT') connections to another, then this problem is trivial to solve. This generally needs a code update (Using Replication for Scale-Out). You will need to direct the 'Update' connections to the master database (or through a dedicated Stingray virtual server), and direct the 'Read' connections to a Stingray virtual server (in 'generic server first' mode) and load-balance the connections across the pool of MySQL slave servers using the 'least connections' loadbalancing method:

Routing connections from the application However, in most cases, you probably don't have that degree of control over how your client application issues MySQL connections; all connections are directed to a single IP:port. A load balancer will need to discriminate between different connection types and route them accordingly.

Routing MySQL traffic

A MySQL database connection is authenticated by a username and password. In most database designs, multiple users with different access rights are used; less privileged user accounts can only read data (issuing 'SELECT' statements), and more privileged users can also perform updates (issuing 'UPDATE' statements). A well architected application with sound security boundaries will take advantage of these multiple user accounts, using the account with least privilege to perform each operation. This reduces the opportunities for attacks like SQL injection to subvert database transactions and perform undesired updates. This article describes how to use Stingray Traffic Manager to inspect and manage MySQL connections, routing connections authenticated with privileged users to the master database and load-balancing other connects to the slaves:

Load-balancing MySQL connections

Designing a MySQL proxy

Stingray Traffic Manager functions as an application-level (layer-7) proxy. Most protocols are relatively easy for layer-7 proxies like Stingray to inspect and load-balance, and work 'out-of-the-box' or with relatively little configuration. For more information, refer to the article Feature Brief: Server First, Client First and Generic Streaming Protocols.

Proxying MySQL connections

MySQL is much more complicated to proxy and load-balance. When a MySQL client connects, the server immediately responds with a randomly generated challenge string (the 'salt'). The client then authenticates itself by responding with the username for the connection and a copy of the 'salt' encrypted using the corresponding password:

Connect and Authenticate in MySQL If the proxy is to route and load-balance based on the username in the connection, it needs to correctly authenticate the client connection first. When it finally connects to the chosen MySQL server, it will then have to re-authenticate the connection with the back-end server using a different salt.

Implementing a MySQL proxy in TrafficScript

In this example, we're going to proxy MySQL connections from two users - 'mysqlmaster' and 'mysqlslave', directing connections to the 'SQL Master' and 'SQL Slaves' pools as appropriate.

The proxy is implemented using two TrafficScript rules ('mysql-request' and 'mysql-response') on a 'serverfirst' Virtual Server listening on port 3306 for MySQL client connections. Together, the rules implement a simple state machine that mediates between the client and server:

Implementing a MySQL proxy in TrafficScript The state machine authenticates and inspects the client connection before deciding which pool to direct the connection to. The rule needs to know the encrypted password and desired pool for each user. The virtual server should be configured to send traffic to the built-in 'discard' pool by default.

The request rule:

Configure the following request rule on a 'server first' virtual server. Edit the values at the top to reflect the encrypted passwords (copied from the MySQL users table) and desired pools:

1. 2. 3. 4. 5. 6. 7. 8.

sub encpassword( $user ) { # From the mysql users table - double-SHA1 of the password # Do not include the leading '*' in the long 40-byte encoded password if( $user == "mysqlmaster" ) return "B17453F89631AE57EFC1B401AD1C7A59EFD547E5"; if( $user == "mysqlslave" ) return "14521EA7B4C66AE94E6CFF753453F89631AE57EF"; } sub pool( $user ) {

9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62.

if( $user == "mysqlmaster" ) return "SQL Master"; if( $user == "mysqlslave" ) return "SQL Slaves"; } $state = connection.data.get( "state" ); if( !$state ) { # First time in; we've just recieved a fresh connection $salt1 = randomBytes( 8 ); $salt2 = randomBytes( 12 ); connection.data.set( "salt", $salt1.$salt2 );

$server_hs = "\0\0\0\0" . # length - fill in below "\012" . # protocol version "Stingray Proxy v0.9\0" . # server version "\01\0\0\0" . # thread 1 $salt1."\0" . # salt(1) "\054\242" . # Capabilities "\010\02\0" . # Lang and status "\0\0\0\0\0\0\0\0\0\0\0\0\0" . # Unused $salt2."\0"; # salt(2) $l = string.length( $server_hs )-4; # Will be <= 255 $server_hs = string.replaceBytes( $server_hs, string.intToBytes( $l, 1 ), 0 ); connection.data.set( "state", "wait for clienths" ); request.sendResponse( $server_hs ); break; } if( $state == "wait for clienths" ) { # We've recieved the client handshake. $chs = request.get( 1 ); $chs_len = string.bytesToInt( $chs ); $chs = request.get( $chs_len + 4 ); # user starts at byte 36; password follows after $i = string.find( $chs, "\0", 36 ); $user = string.subString( $chs, 36, $i-1 ); $encpasswd = string.subString( $chs, $i+2, $i+21 ); $passwd2 = string.hexDecode( encpassword( $user ) ); $salt = connection.data.get( "salt" ); $passwd1 = string_xor( $encpasswd, string.hashSHA1( $salt.$passwd2 ) ); if( string.hashSHA1( $passwd1 ) != $passwd2 ) { log.warn( "User '" . $user . "': authentication failure" ); connection.data.set( "state", "authentication failed" ); connection.discard(); }

63. connection.data.set( "user", $user ); 64. connection.data.set( "passwd1", $passwd1 ); 65. connection.data.set( "clienths", $chs ); 66. 67. connection.data.set( "state", "wait for serverhs" ); 68. request.set( "" ); 69. 70. # Select pool based on user 71. pool.select( pool( $user ) ); 72. 73. break; 74. } 75. 76. if( $state == "wait for client data" ) { 77. # Write the client handshake we remembered from earlier to the server, 78. # and piggyback the request we've just recieved on the end 79. $req = request.get(); 80. 81. 82. $chs = connection.data.get( "clienths" ); 83. $passwd1 = connection.data.get( "passwd1" ); 84. $salt = connection.data.get( "salt" ); 85. 86. $encpasswd = string_xor( $passwd1, 87. string.hashSHA1( $salt . string.hashSHA1( $passwd1 ) ) ); 88. 89. $i = string.find( $chs, "\0", 36 ); 90. $chs = string.replaceBytes( $chs, $encpasswd, $i+2 ); 91. 92. connection.data.set( "state", "do authentication" ); 93. request.set( $chs.$req ); 94. 95. break; 96. } 97. 98. # Helper function 99. 100. sub string_xor( $a, $b ) { 101. $r = ""; 102. while( string.length( $a ) ) { 103. $a1 = string.left( $a, 1 ); $a = string.skip( $a, 1 ); 104. $b1 = string.left( $b, 1 ); $b = string.skip( $b, 1 ); 105. 106. $r = $r . chr( ord( $a1 ) ^ ord ( $b1 ) ); 107. } 108. return $r; 109. }

The response rule

Configure the following as a response rule, set to run every time, for the MySQL virtual server.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42.

$state = connection.data.get( "state" ); $authok = "\07\0\0\2\0\0\0\02\0\0\0"; if( $state == "wait for serverhs" ) { # Read server handshake, remember the salt $shs = response.get( 1 ); $shs_len = string.bytesToInt( $shs )+4; $shs = response.get( $shs_len ); $salt1 = string.substring( $shs, $shs_len-40, $shs_len-33 ); $salt2 = string.substring( $shs, $shs_len-13, $shs_len-2 ); connection.data.set( "salt", $salt1.$salt2 ); # Write an authentication confirmation now to provoke the client # to send us more data (the first query). This will prepare the # state machine to write the authentication to the server connection.data.set( "state", "wait for client data" ); response.set( $authok ); break; } if( $state == "do authentication" ) { # We're expecting two responses. # The first is the authentication confirmation which we discard. $res = response.get(); $res1 = string.left( $res, 11 ); $res2 = string.skip( $res, 11 ); if( $res1 != $authok ) { $user = connection.data.get( "user" ); log.info( "Unexpected authentication failure for " . $user ); connection.discard(); } connection.data.set( "state", "complete" ); response.set( $res2 ); break; }

Testing your configuration

If you have several MySQL databases to test against, testing this configuration is straightforward. Edit the request rule to add the correct passwords and pools, and use the mysql command-line client to make connections: $ mysql -h zeus -u username -p Enter password: *******

Check the 'current connections' list in the Stingray UI to see how Stingray has connected each session to a back-end database server. If you encounter problems, try the following steps: Ensure that trafficscript!variable_pool_use is set to 'Yes' in the Global Settings page on the UI. This setting allows you to use non-literal values in pool.use() and pool.select() TrafficScript functions. Turn on the log!client_connection_failures and log!server_connection_failures settings in the Virtual Server > Connection Management configuration page; these settings will configure the traffic manager to write detailed debug messages to the Event Log whenever a connection fails. Then review your Traffic Manager Event Log and your mysql logs in the event of an error. Stingray's access logging can be used to record every connection. You can use the special *{name}d log macro to record information stored using connection.data.set(), such as the username used in each connection.

Conclusion
This article has demonstrated how to build a fairly sophisticated protocol parser where the Stingray-based proxy performs full authentication and inspection before making a load-balancing decision. The protocol parser then performs the authentication again against the chosen back-end server. Once the client-side and server-side handshakes are complete, Stingray will simply forward data back and fro between the client and the server. This example addresses the problem of scaling out your MySQL database, giving load-balancing and redundancy for database reads ('SELECTs'). It does not address the problem of scaling out your master 'write' server - you need to address that by investing in a sufficiently powerful server, architecting your database and application to minimise the number and impact of write operations, or by selecting a full clustering solution.

The solution leaves a single point of failure, in the form of the master database. This problem could be effectively dealt with by creating a monitor that tests the master database for correct operation. If it detects a failure, the monitor could promote one of the slave databases to master status and reconfigure the 'SQLMaster' pool to direct write (UPDATE) traffic to the new MySQL master server.

Acknowledgements
Ian Redfern's MySQL protocol description was invaluable in developing the proxy code. Appendix - Password Problems? This example assumes that you are using MySQL 4.1.x or later (it was tested with MySQL 5 clients and servers), and that your database has passwords in the 'long' 41-byte MySQL 4.1 (and later) format (see http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html) If you upgrade a pre-4.1 MySQL database to 4.1 or later, your passwords will remain in the pre-4.1 'short' format. You can verify what password format your MySQL database is using as follows:

mysql> select password from mysql.user where user='username'; +------------------+ | password | +------------------+ | 6a4ba5f42d7d4f51 | +------------------+ 1 rows in set (0.00 sec) mysql> update mysql.user set password=PASSWORD('password') where user='username'; Query OK, 1 rows affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select password from mysql.user where user='username'; +-------------------------------------------+ | password | +-------------------------------------------+ | *14521EA7B4C66AE94E6CFF753453F89631AE57EF | +-------------------------------------------+ 1 rows in set (0.00 sec) If you can't create 'long' passwords, your database may be stuck in 'short' password mode. Run the following command to resize the password table if necessary: $ mysql_fix_privilege_tables --password=admin password Check that 'old_passwords' is not set to '1' (see here) in your my.cnf configuration file. Check that the mysqld process isn't running with the --old-passwords option. Finally, ensure that the privileges you have configured apply to connections from the Stingray proxy. You may need to GRANT... TO 'user'@'%' for example. - See more at: http://splash.riverbed.com/docs/DOC1512#sthash.eV78uvsH.dpufhttp://splash.riverbed.com/docs/DOC-1512

Pgina 1 de 7

Servidor de Protocolo de Transferencia de Archivos (FTP)

Etiquetas: ftp

Imprimir Volver a Administracin de...

Table of Contents [-]

1 Acerca del Protocolo FTP 2 Funcionamiento del Protocolo FTP 3 Modos de conexin del cliente FTP 3.1 Modo Activo 3.2 Modo Pasivo 3.3 Modo Activo vs Modo Pasivo 4 Modos de acceso del cliente FTP 4.1 Acceso Annimo 4.2 Acceso de Usuario 4.3 Acceso de Invitado 4.4 Instalando VSFTPD 4.5 Archivos de configuracin de VSFTPD 4.5.1 Configuracin del fichero vsftpd.conf 4.5.2 Configuracin del fichero chroot_list 4.6 Iniciar , detener o reiniciar el servidor FTP 5 Creacin de cuentas de usuario en el servidor FTP

Acerca del Protocolo FTP#

La historia de este protocolo se remonta al ao de 1969 cuando el Instituto Tecnolgico de Massachusetts mejor conocido como el MIT present la propuesta del primer Protocolo para la transmisin de archivos en Internet. *Era un protocolo muy sencillo basado en el sistema de correo electrnico pero sent las bases para el futuro protocolo de transmisin de archivos (FTP). En 1985, quince aos despus de la primera propuesta, se termina el desarrollo del an vigente protocolo para la transmisin de archivos en Internet (FTP), basado en la filosofa de cliente-servidor. Fragmento extrado de Wikipedia El protocolo FTP (File Transfer Protocol) es una de las herramientas mas usadas entorno a la administracin de portales web y tiene como principal funcin la transferencia de archivos. Esta transaccin puede ser efectuada desde una LAN (Red de rea local) o en una WAN (Red de rea Amplia). El protocolo FTP esta basado principalmente en la arquitectura Cliente-Servidor el cual consiste bsicamente en un programa Cliente que realiza peticiones a otro programa Servidor el cual responde a su peticin. Visto de otra forma podemos entenderlo como el equipo cliente que se conecta al servidor para descargar archivos desde el o para enviarle archivos. FTP hace uso del modelo TCP/IP y trabaja directamente sobre la capa de aplicacin del antes mencionado. As mismo el protocolo FTP hace uso de los puertos 20 y 21 para la comunicacin y control de datos. Un problema bsico de FTP es que est pensado para ofrecer la mxima velocidad en la conexin, pero no la mxima seguridad, ya que todo el intercambio de informacin, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningn tipo de cifrado, con lo que un posible atacante puede capturar este trfico mediante la ayuda de un sniffer y acceder al servidor. Una forma de solucionar este gran problema de seguridad es mediante la utilizacin de aplicaciones como SCP y el SFTP los cuales permiten transferir archivos pero cifrando el trafico , por lo general estas aplicaciones son incluidas en el paquete de openSSH tema que veremos mas adelante.

Funcionamiento del Protocolo FTP#

Generalmente se origina cuando el cliente FTP enva la peticin al servidor para indicarle que requiere establecer una comunicacin con el, entonces el cliente FTP inicia la conexin hacia el servidor FTP mediante el puerto 21 el cual establecer un canal de control. A partir de este punto el cliente FTP enviara al servidor las acciones que este debe ejecutar para poder llevar a cabo el envo de datos. Estas acciones incluyen parmetros para la conexin de datos as como tambin la manera en como sern gestionados y tratados estos datos. Algunos de los parmetros enviados por el cliente FTP para la conexin de datos son los siguientes: _ Puerto de datos Modo de transferencia Tipo de representacin y estructura

Los parmetros relacionados a la gestin de datos son los siguientes:

05/11/2011

Pgina 2 de 7

Almacenar Recuperar Aadir Borrar Obtener

El proceso de transferencia de datos desde el servidor hacia el cliente deber esperar a que el servidor inicie la conexin al puerto de datos especificado ( en modo activo ) y luego de ello transferir los datos en funcin a los parmetros de conexin especificados anteriormente.

Modos de conexin del cliente FTP#

FTP establecer dos modos de conexin diferentes para el cliente, el Modo Activo y el Modo Pasivo.

Modo Activo#
El modo activo generalmente es conocido tambin como modo estndar y este opera de la siguiente forma. Se establecen dos conexiones distintas, la primera conexin establece una comunicacin para la transmisin de comandos a travs de un puerto aleatorio mayor que el 1024 del cliente FTP hacia el puerto 21 del servidor FTP y por esa misma conexin se le notifica al servidor FTP cual es el puerto de nuestro cliente FTP que esta a la espera de los datos. Entonces y para comprender mejor, si usted descarga algn archivo mediante la ayuda de algn cliente de FTP, es el servidor FTP el que inicia la transmisin de datos, desde su puerto 20 al puerto que aleatoriamente el cliente FTP le ha indicado. Se le llama modo activo porque la transmisin de datos es iniciada por el propio servidor FTP.

Modo Pasivo#
Esto se logra cuando el cliente FTP inicia la conexin con el servidor FTP mediante el envi del comando PASV en este punto el cliente FTP establece una comunicacin mediante un canal de control el cual generalmente utiliza un puerto aleatorio mayor al 1024 para comunicarse con el servidor FTP a travs de su puerto 21. Al pasar a modo pasivo el cliente FTP pedir al servidor FTP que habr un puerto, el cual deber ser aleatorio y mayor al 1024, recibida la contestacin, ser el cliente FTP el que establezca la conexin de datos al servidor FTP a travs del puerto especificado anteriormente.

Modo Activo vs Modo Pasivo#

Como hemos explicado antes, en el modo activo se abre una conexin para datos desde el servidor FTP al cliente FTP, esto es, una conexin de fuera hacia adentro, entonces, si el cliente FTP se encuentra detrs de un firewall, este filtrara o bloqueara la conexin entrante. En el modo pasivo es el cliente FTP el que inicia tanto la conexin de control como la de datos, con lo cual el firewall no tendr ninguna conexin entrante que filtrar.

Modos de acceso del cliente FTP#

Un cliente FTP es la aplicacin o software que servir de intermediario entre el servidor FTP y nuestro equipo, as mismo existen dos versiones de clientes FTP, los grficos y los que se usan a linea de comandos. En la mayora de los casos se implementaran clientes grficos de FTP esto debido a que son mas fciles y sencillos de manejar por el usuario. Nosotros recomendamos usar el cliente FTP FileZilla. FileZilla es un cliente FTP, gratuito, multiplataforma , libre y de cdigo abierto. Sustenta los protocolos FTP, SFTP y SFTP. As mismo, los clientes FTP pueden acceder a los servidores FTP de tres formas distintas, estas son: Acceso Annimo Acceso de Usuario Acceso de Invitado

Acceso Annimo#
El acceso annimo a un servidor FTP se caracteriza porque este no pide ningn tipo de autenticacion al cliente FTP ( login y password ) para entrar en el. Generalmente este tipo de accesos son implementados para que cualquier usuario tenga acceso a los recursos que ah se comparten, los cuales normalmente solo pueden ser ledos o copiados , restringiendo a los usuarios la funcin de crear o modificar dichos recursos.

Acceso de Usuario#
Este tipo de acceso se caracteriza porque este si requiere autenticacion del cliente FTP ( login y password ) ante el servidor FTP. Generalmente estos accesos son implementados para un grupo selecto de usuarios, los cuales tendrn ciertos privilegios sobre los

05/11/2011

Pgina 3 de 7

recursos del servidor como podra ser modificar, eliminar, crear , subir o descargar archivos o carpetas. Otra caracterstica de este acceso es que permite al usuario FTP acceder a cualquier parte del sistema operativo, lo cual es un grave fallo de seguridad.

Acceso de Invitado#
El acceso de invitado bien podra ser un hbrido entre el acceso annimo y el acceso de usuario, ya que en este tipo de acceso de requiere autenticacion del cliente FTP ( login y password ) ante el servidor FTP, lo que lo diferencia de los ltimos dos es que el usuario FTP solo podr trabajar en un directorio de trabajo destinado exclusivamente para el, evitando as que el usuario FTP tenga acceso a otras partes del sistema operativo, pero sin restringir los privilegios que tiene sobre su propio directorio de trabajo. Proceso de instalacin del servidor FTP

Instalando VSFTPD#
La instalacin de VSFTPD es relativamente sencilla , solo debe teclear en terminal el siguiente comando. [root@ localhost ~]# yum install -y vsftpd Recuerde que este comando se debe ejecutar como root

Archivos de configuracin de VSFTPD#

La configuracin de VSFTPD se realizara sobre dos ficheros distintos, uno de configuracin general propio de VSFTPD y otro para especificar al servidor FTP los usuarios que harn uso del acceso de invitado. El primer fichero de configuracin de VSFTPD lo encontramos en la siguiente ruta /etc/vsftpd/vsftpd.conf El segundo fichero de configuracin debe ser creado por usted mismo ya que de otra forma nunca podr especificar al servidor FTP los usuarios que harn uso del acceso de invitado. La ruta en la que se debe crear dicho fichero es la siguiente: /etc/vsftpd Y sera nombrado con el nombre siguiente: chroot_list A este fichero debern ser agregados los nombres de los usuarios de FTP que trabajaran en su directorio de trabajo, de esta manera se restringe a estos usuarios el acceso a otras partes del sistema operativo, cualquier otro usuario no agregado a este archivo podr acceder a cualquier parte del sistema operativo, lo cual es un grave fallo de seguridad. Al final nuestros archivos debern estar ubicados en las siguientes ruta: /etc/vsftpd/vsftpd.conf /etc/vsftpd/chroot_list ---> ---> Fichero de configuracin propio de VSFTPD Fichero que definir los usuarios que harn uso del acceso de invitado [RECUERDE QUE ESTE FICHERO DEBE SER GENERADO POR USTED]

El siguiente paso sera editar y configurar los ficheros que previamente creamos.
Configuracin del fichero vsftpd.conf#
Para llevar a cabo la configuracin de este fichero le recomendamos usar el editor de textos VIM. A continuacin le presentamos las diferentes opciones que pueden ser habilitadas o negadas en el fichero de configuracin vsftpd.conf

Habilitando o negando accesos annimos al servidor FTP Al haber abierto el fichero trate de buscar la linea siguiente: Para habilitar el acceso annimo al servidor FTP solo deber teclear la palabra YES , caso contrario si usted desea tener deshabilitada esta opcin solo deber teclear la palabra NO.
anonymous_enable=YES|NO

Habilitar o negar autenticarse a los usuarios

05/11/2011

Pgina 4 de 7

Para habilitar o negar los accesos autenticados de los usuarios locales en el servidor FTP deber buscar la siguiente linea:
local_enable=YES|NO Deber teclear la palabra YES para habilitar la autenticacion , caso contrario si usted desea tener deshabilitada esta opcin solo deber teclear la palabra NO.

Habilitar o negar la escritura en el servidor FTP Para habilitar o negar la escritura en el servidor FTP deber buscar la siguiente linea
write_enable=YES|NO Una vez ubicada esta linea recuerde borrar ( si es que esta ) el signo de numero (#) para habilitar esta funcin. Establezca el valor YES o NO de acuerdo a lo que se requiera.

Estableciendo un mensaje de bienvenida en el servidor FTP Este parmetro sirve para establecer un mensaje de bienvenida el cual ser mostrado cada vez que un usuario acceda al servidor de archivos. Una vez ubicada esta linea recuerde borrar ( si es que esta ) el signo de numero (#) para habilitar esta funcin. Para agregar este mensaje al servidor FTP deber buscar la siguiente linea y editarla.
ftpd_banner=Bienvenido al Servidor FTP de Linux Para Todos

Habilitar el acceso de invitado para ciertos usuarios de FTP Para limitar a los usuarios a trabajar en su propia carpeta de trabajo se debern editar las siguientes lineas del fichero vsftpd.conf
chroot_list_enable=YES |NO Una vez ubicada esta linea recuerde borrar ( si es que esta ) el signo de numero (#) para habilitar esta funcin. Habilitar este parmetro indicara al servidor FTP que el usuario solo podr trabajar dentro de su carpeta de trabajo, para ello solo habr que teclear la palabra YES, en caso contrario use la palabra NO El siguiente parmetro se encuentra en funcin del anterior, de forma que si usted lo habilito tambin tendr que habilitar este ultimo, para ello solo deber borrar el caracter de numero (#) chroot_list_file=/etc/vsftpd/chroot_list El parmetro /etc/vsftpd/chroot_list indica la ruta en la cual se encuentra el fichero con los nombres de los usuarios que sern limitados a trabajar en su propia carpeta de trabajo Recuerde que usted creo previamente este fichero

Habilitar al usuario annimo la funcin de subir contenido al servidor FTP Para habilitar o negar al usuario annimo el subir datos al servidor FTP deber buscar la siguiente linea:
anon_upload_enable=YES|NO Una vez ubicada esta linea recuerde borrar ( si es que esta ) el signo de numero (#) para habilitar esta funcin. Establezca el valor YES o NO de acuerdo a lo que se requiera.

Habilitar al usuario annimo la funcin de crear carpetas en servidor FTP Para habilitar o negar al usuario crear carpetas en servidor FTP deber buscar la siguiente linea:

05/11/2011

Pgina 5 de 7

anon_mkdir_write_enable=YES|NO Una vez ubicada esta linea recuerde borrar ( si es que esta ) el signo de numero (#) para habilitar esta funcin. Establezca el valor YES o NO de acuerdo a lo que se requiera.

Estableciendo permisos de escritura, lectura y ejecucin al contenido albergado en el servidor FTP La siguiente linea Indica que los archivos subidos al servidor quedarn con los permisos 022, es decir, slo escritura para el grupo y los dems.
local_umask=022 Si tu deseas agregar otro tipo de permisos sobre el contenido que sera albergado en tu servidor FTP solo debers modificar el valor 022 por el que tu creas mas conveniente. Nosotros recomendamos usar el permiso 664 local_umask=664 es decir, lectura y escritura para el propietario del fichero, y slo lectura para el grupo y los dems

Limitando la tasa de transferencia a los usuarios annimos Usted puede limitar la tasa de transferencia ( en bytes ) para los usuarios annimos, solamente deber agregar la siguiente linea al final del archivo
anon_max_rate=10240 Como podemos observar hemos limitado la tasa de transferencia a solo 10 Kb para los usuarios annimos, usted podr definir ese parmetro de acuerdo a sus necesidades.

Limitando la tasa de transferencia a los usuarios autenticados Usted puede limitar la tasa de transferencia ( en bytes ) para los usuarios annimos, solamente deber agregar la siguiente linea al final del archivo
local_max_rate=10240 Como podemos observar hemos limitado la tasa de transferencia a solo 10 Kb para los usuarios autenticados, usted podr definir ese parmetro de acuerdo a sus necesidades.

Limitando el numero de conexiones hacia el servidor FTP Usted podr establecer un numero mximo de conexiones que podrn acceder simultneamente al servidor FTP, para ello solo habr que aadir la siguiente linea al final de archivo.
max_clients=3 Como podemos observar hemos limitado el acceso a solamente 3 clientes FTP

Limitando el numero de conexiones por IP hacia el servidor FTP Usted podr establecer un numero mximo de conexiones desde una misma direccin IP que podrn acceder simultneamente al servidor FTP, para ello solo habr que aadir la siguiente linea al final de archivo.
max_per_ip=3 Como podemos observar hemos limitado el acceso a simultaneo a solamente 3 IPs .

05/11/2011

Pgina 6 de 7

Configuracin del fichero chroot_list#

La configuracin de este fichero es relativamente fcil, solo deber aadir dentro de el los nombres de los usuarios que sern limitados a trabajar dentro de su carpeta personal de trabajo. Ejemplo: [root@ localhost ~]# vim /etc/vsftpd/chroot_list paty angelica erika viridiana iliana regina "chroot_list"

Al terminar solo deber guardar los cambios hechos al fichero.

Iniciar , detener o reiniciar el servidor FTP#

Para iniciar el servidor FTP por primera vez solo deber teclear en terminal el siguiente comando: [root@ localhost ~]# /etc/init.d/vsftpd start

Igualmente existen opciones ya sea para reiniciar, detener, recargar o conocer el status en el que se encuentra el servidor FTP. Estas opciones pueden ser consultadas en la siguiente tabla:
start stop restart Inicia el servicio Detiene el servicio Reinicia el servicio.-La diferencia con reload radica en que al ejecutar un restart este mata todos los procesos relacionado con el servicio y los vuelve a generar de nueva cuenta Recarga el servicio.-La diferencia con restart radica en que al ejecutar un reload este solamente carga las actualizaciones hechas al fichero de configuracin del servicio sin necesidad de matar los procesos relacionados con el mismo, por lo que podra entenderse que hace el cambio en caliente.

reload

condrestartReinicio Condicional.- Solamente se inicia si el servicio se encuentra ejecutndose. status Da a conocer el estado en el que se encuentra el servicio Como alternativa tambin podemos ocupar el siguiente comando para iniciar el servidor FTP [root@ localhost ~]# service vsftpd start

Y de igual manera podemos usar las opciones antes descritas en la tabla anterior. Recuerde que estos comandos se ejecutan como root.

Creacin de cuentas de usuario en el servidor FTP#

Crear cuentas de usuario en el servidor FTP es un proceso muy parecido a dar de alta usuarios en Linux. La sintaxis general para dar de alta usuarios es la siguiente: Las opciones utilizadas son explicadas en la siguiente tabla: Opciones Descripcin

-d |

Carpeta de trabajo que sera asignado al usuario Ejemplos: a) -d /home/usuario1 --home b) -d /home/cmartinez c) -d /home/icastillo -s /sbin/nologin El usuario no podr logearse en el sistema. Ideal para usuarios con acceso a Samba o FTP pero sin --shell acceso al interprete de comandos.

-s |

Adicionalmente se tiene que asignar una contrasea al usuario FTP.

[root@ localhost ~]# passwd sistemas Cambiando la contrasea del usuario . Nueva UNIX contrasea: xxxxxxxxxx

05/11/2011

Pgina 7 de 7

Vuelva a escribir la nueva UNIX contrasea:xxxxxxxxxx passwd: todos los tokens de autenticacin se actualizaron exitosamente.

Ejemplo:
[root@ localhost ~]# useradd -d /home/ftp/javier -s /sbin/nologin \ > javier Explicacin: Como podemos observar, estamos creando una cuenta en el servidor ftp, para ello estamos usando el comando useradd El parmetro siguiente es -d /home/ftp/javier Este parmetro le indica a Linux que la carpeta de trabajo de javier esta ubicada en la ruta /home/ftp/javier, el ultimo parmetro -s /sbin/nologin Le indica a Linux que el usuario no podr logearse en el sistema lo cual es ideal para usuarios con acceso a FTP pero sin acceso al interprete de comandos. 0 archivos adjuntos 28581 Accesos

Promedio (2 Votos)

Comentarios

05/11/2011

Pgina 1 de 11

Servidor LAMP en CentOS

Table of Contents [-]
1 Sobre LAMP 2 Proceso de instalacin de LAMP 2.1 Instalando el servidor LAMP(Apache+MySQL+PHP) 3 Descargando Joomla 4 Configurando dominios virtuales en Apache 4.1 Paso 1.- Activando la directiva NameVirtualHost 4.2 Paso 2.- Estructura de directorios para dominios virtuales 4.3 Paso 3.- Creacin y modificacin de los ficheros de configuracin de los dominios virtuales 4.4 Paso 4.- Integrando el gestor de contenidos Joomla a los dominios virtuales 5 Configurando MySQL 5.1 Acerca de MySQL 5.2 Configurando la cuenta de root en el manejador MySQL 5.3 Integrando MySQL con Joomla 6 Instalacin de Joomla 6.1 Sobre Joomla 6.2 Instalando Joomla 6.2.1 Paso 1) Seleccionando el idioma para la instalacin 6.2.2 Paso 2) Comprobacin de paquetes para Joomla 6.2.3 Paso 3) Licencia GNU/GPL 6.2.4 Paso 4) Configurando MySQL con Joomla 6.2.5 Paso 5) Configurando el FTP 6.2.6 Paso 6) Configuracin Principal de Joomla 6.2.7 Paso 7) Finalizando la instalacin de Joomla 6.2.8 Accediendo a la consola de administracin de Joomla 6.2.9 Accediendo a nuestro portal web

Imprimir Volver a Servidor LAMP...

Sobre LAMP#
Un servidor LAMP es un conjunto de aplicaciones instaladas en un servidor Linux los cuales, al trabajar en conjunto logran dar vida a una aplicacin mucho mas grande y robusta

Generalmente un servidor LAMP esta constituido por los siguientes paquetes:

Linux: El sistema operativo; Apache. El servidor web; MySQL. El gestor de bases de datos; Perl, PHP, o Python. Lenguajes de programacin.

De ah el nombre de servidor LAMP Algunas aplicaciones que hacen uso de un servidor LAMP son las siguientes:
Zimbra.-Servidor de Correo Electrnico Openfire.-Servidor de Mensajera Instantnea CMS.- Gestores de Contenidos (Joomla,Drupal,Wordpress)

Proceso de instalacin de LAMP#

En este capitulo te ensearemos como se instala y configura un servidor de LAMP mediante la implementacion de un gestor de contenidos que en este caso sera un Joomla.

Instalando el servidor LAMP(Apache+MySQL+PHP)#

La instalacin de un servidor LAMP requiere de aplicaciones previamente instaladas como es el caso del servidor web apache el cual fue instalado en el capitulo anterior pero de igual manera lo volveremos a nombrar aqu.

Abra una consola y teclee lo siguiente para llevar a cabo la instalacin de los paquetes del servidor LAMP
[root@ localhost ~]# yum install -y httpd mysql mysql-server php-mysql php-cli php-common Recuerde que este comando se debe ejecutar como root Por ultimo solo deber iniciar (o en su caso reiniciar) servicios como el servidor web apache asi como tambin el manejador de bases de datos MySQL [root@ localhost ~]# /etc/init.d/httpd start [root@ localhost ~]# /etc/init.d/mysql start

El siguiente punto sera descargar el gestor de contenidos Joomla.

05/11/2011

Pgina 2 de 11

Descargando Joomla#
Descargue Joomla del siguiente portal web: [http://www.joomlaspanish.org/]

Como puede observarse usted puede descargar Joomla de tres formas distintas, la nica diferencia radica en la forma en la que esta empaquetado el paquete. Le recomendamos descargar Joomla a la carpeta de root
------> /root/Joomla_1.5.9-Spanish-pack_completo.tar.gz

NOTA: No extraiga o desempaquete el gestor de contenidos, solo descarguelo en la ruta antes mencionada , posteriormente se le indicara donde debe ser extrado el contenido de este paquete

Configurando dominios virtuales en Apache#

Como podr recordar en el capitulo anterior hablamos extensamente sobre el tema de los dominios virtuales en apache, pero de igual manera volveremos a retomar el tema aqu

La creacin de dominios virtuales sobre un servidor web como apache tiene una vital importancia cuando se trata de dar hospedaje a varios sitios web dentro del mismo servidor. Lograr implementar de manera correcta los dominios virtuales sobre el servidor web apache es tarea sencilla por lo que le recomendamos primero haber ledo todas las directivas que pueden ser aplicadas al fichero
httpd.conf

A partir de este punto comenzaremos a crear los dominios virtuales, es por ello que pedimos tu total concentracin y paciencia para que leas poco a poco estos puntos.

Paso 1.- Activando la directiva NameVirtualHost#

El primer paso sera abrir el fichero httpd.conf el cual esta almacenado en la ruta: /etc/httpd/conf/

En dicho fichero debemos localizar la siguiente linea y descomentarla si es que lo esta

NameVirtualHost *:80

La funcin de esta directiva sirve para indicar la direccin IP en la que se esta brindando el servicio o bien insertando un asterisco (*) para que est activa en cualquier interfaz del servidor que es como nosotros lo debemos tener.

Paso 2.- Estructura de directorios para dominios virtuales #

Lo siguiente sera crear la estructura que contendr cada uno de los dominios virtuales que sern hospedados en nuestro servidor. Ejemplo: Suponga que tenemos 5 nombres de dominio que sern hospedados en nuestro servidor web www.turbolinux.com.mx www.comerciolinux.com www.escuelalinux.edu www.linuxunido.org www.linuxbloger.net

05/11/2011

Pgina 3 de 11

por cada dominio se deber crear un directorio, dicho directorio sera nombrado de la misma forma que el dominio, solo omitiendo el www. [root@ [root@ [root@ [root@ [root@ localhost localhost localhost localhost localhost ~]# ~]# ~]# ~]# ~]# mkdir mkdir mkdir mkdir mkdir turbolinux.com.mx comerciolinux.com escuelalinux.edu linuxunido.org linuxbloger.net

Estos directorios debern ser creados dentro de la ruta /var/www/ Al final estos directorios debern quedar de la siguiente manera /var/www/turbolinux.com.mx /var/www/comerciolinux.com /var/www/escuelalinux.edu /var/www/linuxunido.org /var/www/linuxbloger.net Si no estn en la ruta antes descrita solo debe moverlos con el comando mv. Lo siguiente sera crear dentro de cada uno de estos directorios la estructura bsica que debe llevar cada uno de estos dominios. Esta estructura estar conformada por cuatro directorios: html cgi-bin icons error

por lo que deber crear estos cuatro directorios para cada uno de los directorios de dominio. Ejemplo para el dominio turbolinux.com.mx
# # # # mkdir mkdir mkdir mkdir /var/www/turbolinux.com.mx/html /var/www/turbolinux.com.mx/cgi-bin /var/www/turbolinux.com.mx/icons /var/www/turbolinux.com.mx/error

y asi para los siguientes restantes dominios.

Paso 3.- Creacin y modificacin de los ficheros de configuracin de los dominios virtuales #
Una vez creadas las carpetas de dominios asi como tambin la estructura de cada uno pasaremos al ultimo paso, crear los ficheros de configuracin correspondientes a cada dominio.

Nuevamente por cada dominio se deber crear un fichero de configuracin, dicho fichero sera nombrado de la misma forma que el dominio, solo omitiendo el www.
[root@ [root@ [root@ [root@ [root@ localhost localhost localhost localhost localhost ~]# ~]# ~]# ~]# ~]# mkdir mkdir mkdir mkdir mkdir turbolinux.com.mx.conf comerciolinux.com.conf escuelalinux.edu.conf linuxunido.org.conf linuxbloger.net.conf

Estos directorios debern ser creados dentro de la ruta

/etc/httpd/conf.d/ Al final estos directorios debern quedar de la siguiente manera /etc/httpd/conf.d/turbolinux.com.mx.conf /etc/httpd/conf.d/comerciolinux.com.conf /etc/httpd/conf.d/escuelalinux.edu.conf /etc/httpd/conf.d/linuxunido.org.conf /etc/httpd/conf.d/linuxbloger.net.conf Si no estn en la ruta antes descrita solo debe moverlos con el comando mv Lo siguiente sera crear dentro de cada uno de estos ficheros la estructura bsica que deben contener para que puedan ser ledos por el fichero principal de configuracin de apache, nos referimos al fichero httpd.conf . Esta estructura estar conformada por la siguiente configuracin bsica: Ejemplo para el dominio turbolinux.com.mx <VirtualHost *:80> ServerAdmin administrador@tuDominio.net DocumentRoot "/var/www/turbolinux.com.mx/html" ServerName www. turbolinux.com.mx ServerAlias turbolinux.com.mx </VirtualHost>

Los parmetros usados son descritos en la siguiente tabla:

05/11/2011

Pgina 4 de 11

VirtualHost

La funcin de esta directiva sirve para indicar la direccin IP en la que se esta brindando o bien insertando un asterisco(*) para que est activa en cualquier interfaz del servidor que es como nosotros lo debemos tener. ServerAdmin Esta directiva especifica la persona a la que se le debe notificar los problemas referentes al portal web , esto a travs de su cuenta de correo. DocumentRootEsta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros web de tu sitio principal. Esta directiva especifica el nombre y puerto que el servidor utiliza para identificarse. Con una correcta configuracin, este valor se puede determinar ServerName automticamente, pero es recomendable especificarlo explciatamente para evitar problemas durante el arranque. ServerAlias Esta directiva sirve para que el mismo sitio web sea accesible desde distintos nombres de dominio. Ejemplo: turbolinux.com.mx ---> www.turbolinux.com.mx

Paso 4.- Integrando el gestor de contenidos Joomla a los dominios virtuales#

El ultimo paso sera colocar en la carpeta html de cada uno de los dominios virtuales el paquete que descargamos del portal http://www.joomlaspanish.org/ nos referimos al gestor de contenidos Joomla, por lo que solo bastara con copiar y pegar en cada uno de los directorios html de cada dominio una copia del mismo. # cp /root/Joomla_1.5.9-Spanish-pack_completo.tar.gz > /var/www/turbolinux.com.mx/html/ # cp /root/Joomla_1.5.9-Spanish-pack_completo.tar.gz > /var/www/comerciolinux.com/html/ # cp /root/Joomla_1.5.9-Spanish-pack_completo.tar.gz > /var/www/escuelalinux.edu/html/ # cp /root/Joomla_1.5.9-Spanish-pack_completo.tar.gz > /var/www/linuxunido.org/html/ # cp /root/Joomla_1.5.9-Spanish-pack_completo.tar.gz > /var/www/linuxbloger.net/html/ \

Lo siguiente sera extraer el contenido del paquete Joomla_1.5.9-Spanish-pack_completo.tar.gz dentro del directorio html de cada uno de los dominios virtuales
[root@ localhost ~]# tar -xzvf Joomla_1.5.9-Spanish-pack_completo.tar.gz

Al terminar deber borrar el paquete Joomla_1.5.9-Spanish-pack_completo.tar.gz de cada uno de los directorios html de cada dominio El siguiente paso sera configurar el servidor de base de datos MySQL para que funcione en sincrona con Joomla

Configurando MySQL#
Acerca de MySQL#
MySQL es un sistema de gestin de base de datos relacional, multihilo y multiusuario con ms de seis millones de instalaciones. Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero las empresas que quieran incorporarlo en productos privativos pueden comprar a la empresa una licencia especfica que les permita este uso. Est desarrollado en su mayor parte en ANSI C.

Al contrario que proyectos como Apache, donde el software es desarrollado por una comunidad pblica y el copyright del cdigo est en poder del autor individual, MySQL es propiedad y est patrocinado por una empresa privada, que posee el copyright de la mayor parte del cdigo. Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Adems de la venta de licencias privativas, la compaa ofrece soporte y servicios. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran va Internet. MySQL AB fue fundado por David Axmark, Allan Larsson, y Michael Widenius y desde enero de 2008 es una subsidiaria de Sun Microsystems

Configurando la cuenta de root en el manejador MySQL #

Para comenzar a manipular los accesos del usuario root al manejador MySQL primero tendr que tener levantado a MySQL de lo contrario le arrojara un error en consola cuando intente entrar a MySQL . Si aun no levanta el servicio de MySQL hgalo [root@localhost]# /etc/init.d/mysqld start si lo tiene levantado haga caso omiso de este comentario Una vez levantado el servidor MySQL deberemos asignar un password a la cuenta de root , para ello teclearemos en consola lo siguiente: [root@localhost]# mysql -u root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 to server version: 5.0.27 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> <---[En este punto hemos entrado al modo consola de MySQL]

Para asignar un password al usuario root solo bastara con teclear la siguiente sentencia SQL

05/11/2011

Pgina 5 de 11

mysql>SET PASSWORD FOR 'root'@'localhost' = PASSWORD('PASSWORD');

Obviamente deber cambiar la palabra PASSWORD por la contrasea que desea asignar a root. Si todo marcho, salga del manejador de datos MySQL y trate de logearse nuevamente a MySQL pero ahora proporcionando la contrasea que acaba de asignar mediante el uso del parmetro -p
[root@localhost]# mysql -u root -p Enter password: xxxxxxxx Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: 5.0.67 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql>

Integrando MySQL con Joomla#

Ahora que tenemos ya instalado tanto al gestor de contenidos Joomla como el manejador de Bases de datos MySQL , solo nos resta integrar estas dos aplicaciones para que operen de manera conjunta.

Para ello tendremos que generar en el manejador MySQL lo siguiente:

Una cuenta para el aministrador de Joomla Un password para la cuenta de administrador de Joomla Una base de Datos para el gestor de contenidos Joomla Esta cuenta de usuario sera la asignada al administrador del gestor de contenidos Joomla Sera el password asignado a la cuenta del administrador del gestor de contenidos Joomla Base de Datos en la cual sern dados de alta los usuarios de este gestor de contenidos, nos referimos nuevamente a Joomla

Una vez ledo lo anterior comenzaremos por crear la base de datos que usara el gestor de contenidos Joomla asi como tambin el alta de la cuenta de administrador de Joomla y la asignacin de un password para el mismo, para ello abriremos una terminal y nos pasaremos al modo consola de MySQL como se muestra a continuacin:
[root@localhost]# mysql -u root -p Enter password: **************** Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 4 Server version: 5.0.45 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql>

Una vez dentro creamos la base de datos que usara Joomla. Para generar la base de datos solo basta teclear lo siguiente:
Mysql> CREATE DATABASE joomla; Query OK, 1 row affected (0.00 sec) mysql>

El siguiente paso es asignarle al administrador de joomla una cuenta dentro de MySQL y luego de ello asignarle a este usuario permisos de lectura, escritura y ejecucin sobre la base de datos que antes creamos, esto se consigue de la siguiente manera.
mysql> GRANT ALL ON joomla.* TO 'adminjoomla'@'localhost' IDENTIFIED BY 'PASSWORD' WITH GRANT OPTION; Query OK, 0 rows affected (0.00 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) mysql>

Obviamente deber cambiar la palabra PASSWORD por la contrasea que desea asignar al usuario adminjoomla. Al terminar teclee la palabra exit para salir de MySQL.
mysql>exit Bye Por ultimo,solo tendr que reiniciar el servidor de bases de datos MySQL asi como tambin el de apache [root@ localhost ~]# /etc/init.d/httpd restart [root@ localhost ~]# /etc/init.d/mysql restart

05/11/2011

Pgina 6 de 11

Solo para recordar lo antes visto te posteo una tabla de bastante utilidad
Nombre de la cuenta del adminsitrador de Joomla adminjoomla Contrasea asignada a adminjoomla Recuerde que esta contrasea la asigna usted Nombre de la base de datos asignada a Joomla joomla

NOTA: Si usted olvido la contrasea que asigno para el administrador de Joomla no se preocupe, el fichero
.mysql_history

Guarda el histrico de las acciones que se llevaron a cabo en el servidor de base de datos de MySQL por lo que podr consultarlo para obtener la contrasea si es que la olvido. Generalmente este fichero se encuentra depositado en el directorio de trabajo de root

Instalacin de Joomla #
Al llegar a este punto usted deber contar con su servidor web configurado para dominios virtuales y dentro de cada dominio virtual tener depositado el contenido del paquete de Joomla, asi mismo tambin debe contar con la base de datos de Joomla activas.

Una vez confirmada esta informacin podemos continuar con la ultima parte de este capitulo, nos referimos a la instalacin del gestor de contenidos Joomla

Sobre Joomla#
Joomla es un sistema de administracin de contenidos de cdigo abierto construido con PHP bajo una licencia GPL. Este administrador de contenidos se usa para publicar portales web en Internet mediante la implementacion de un servidor LAMP. En Joomla se incluyen caractersticas como:
Indexamiento web Feed RSS Versiones imprimibles de pginas Flash con noticias Blogs Foros Encuestas Calendario Bsqueda en el sitio web

Instalando Joomla#
El proceso para llevar a cabo la instalacin de Joomla sera el siguiente:

Abra un navegador web, de preferencia que sea Morilla Firmale y en la barra de direcciones teclee el nombre de alguno de los sitios web virtuales que configuramos en el servidor de apache, nosotros elegimos acceder al portal web
www.turbolinux.com.mx

Usted puede acceder a cualquiera de los otros cuatro que se crearon. Una vez dentro del portal web podremos visualizar el Instalador de Joomla el cual consta de 7 pasos para su instalacin Estos pasos son:
Paso 1) Seleccionando el idioma para la instalacin #

Este paso es relativamente sencillo, solo debemos elegir el idioma en el cual queremos que se instale Joomla, es este caso nuestra eleccin sera es-ES-Spanish (Espaol Internacional) y dar clic Siguiente.

Paso 2) Comprobacin de paquetes para Joomla#

El paso 2 se encarga de verificar que las bases da datos creadas para Joomla asi como algunas caractersticas mas estn activas y en perfecto funcionamiento, aqu solo deberemos dar clic en siguiente.

05/11/2011

Pgina 7 de 11

Paso 3) Licencia GNU/GPL#

Aqu solo habr que aceptar la licencia bajo la cual se distribuye Joomla y dar nuevamente clic en siguiente.

Paso 4) Configurando MySQL con Joomla#

En este paso tendremos que introducir los siguientes datos:

Tipo de base de datos----> mysql Nombre Del Servidor ---->localhost Nombre Del Usuario ----> adminjoomla (Este usuario lo creo usted) Contrasea ------>esta contrasea la asigno usted Nombre de la base de datos ---> joomla (Esta base de datos usted la creo)

Al final su configuracin tendr que verse de la siguiente manera:

05/11/2011

Pgina 8 de 11

Daremos clic en siguiente y si todo marcha bien nos direccionara a otra pagina.
Paso 5) Configurando el FTP#

Este paso es irrelevante para este capitulo por lo que daremos clic nuevamente en siguiente:

Paso 6) Configuracin Principal de Joomla#

Este paso es el mas importante de todos, aqu usted tedra que llenar algunos campos relevantes para la configuracin de Joomla. La primera seccin consta de lo siguiente: Nombre del Sitio Web: En este campo usted tendr que teclear el nombre del portal web, en este caso nosotros pondremos www.turbolinux.com.mx

Confirmacin del correo electrnico y contrasea del usuario admin: Aqu usted tendr que llenar los campos referentes al correo electrnico de la persona que sera el administrador de este portal web asi como tambin la asignacin de una contrasea para el mismo. Con esta contrasea y el usuario admin podr ingresar al rea de administracin una vez finalizada la instalacin.

Subir datos de ejemplo, restaurar o migrar contenido de respaldo: Se recomienda a los principiantes que instalen el contenido de ejemplo en espaol o en su idioma. Para esto es necesario seleccionar esa opcin y hacer clic sobre el botn Instalar los datos de ejemplo predefinidos y luego de ello hacer clic en siguiente.

05/11/2011

Pgina 9 de 11

Paso 7) Finalizando la instalacin de Joomla#

Para finalizar la instalacin debe eliminar completamente el directorio de instalacin de Joomla ya que por motivos de seguridad no podr avanzar ms all de esa pantalla hasta que el directorio "installation" sea removido completamente. Esta es una caracterstica de seguridad de Joomla. La ruta del directorio installation la podemos ubicar en:
/var/www/turbolinux.com.mx/html/ -----> installation

el mismo procedimiento tendr que ser ejecutado para los dems dominios en los que instalemos Joomla. Una vez borrado el directorio podremos dar clic en el botn Portada, el cual nos direccionara a la pagina principal de turbolinux.com.mx

Accediendo a la consola de administracin de Joomla#

Para acceder a la consola de administracin de joomla solo basta teclear la siguiente ruta en nuestro navegador web. Www.turbolinux.com.mx/administrator

Nos deber mostrar algo parecido a esto:

En ella tendremos que teclear el nombre de usuario del administrador de Joomla asi como la contrasea que asignamos en el paso 6
Nombre de Usuario---> admin (Este login esta predefinido por Joomla) Contrasea ---> Esta contrasea fue creada por usted Al haber pasado la autenticacion nos direccionara a la siguiente pantalla

05/11/2011

Pgina 10 de 11

En esta consola podr modificar los atributos visuales y de administracin de su portal web.
Accediendo a nuestro portal web#

Para acceder a la pagina principal de nuestro portal web solo habr que teclear en la barra de direcciones de cualquier navegador web (preferenteme firefox) el nombre de nuestro portal web, en este caso www.turbolinux.com.mx el cual deber lucir asi:

05/11/2011

Pgina 11 de 11

0 archivos adjuntos

8599 Accesos

Promedio (0 Votos)

Comentarios

05/11/2011

Pgina 1 de 17

Servidor Web Apache en CentOS

Table of Contents [-]

Imprimir Volver a Servidor Web

1 Como empez todo 2 Proceso de instalacin del servidor web Apache 2.1 Instalando el servidor web apache 2.2 Archivos de configuracin del servidor web Apache 2.2.1 Configuracin del fichero httpd.conf 2.3 Iniciar , detener o reiniciar el servidor web Apache 3 Creacin de dominios virtuales en Apache 3.1 Paso 1.- Activando la directiva NameVirtualHost 3.2 Paso 2.- Estructura de directorios para dominios virtuales 3.3 Paso 3.- Creacin y modificacin de los ficheros de configuracin de los dominios virtuales 4 Como empez todo 5 Proceso de instalacin del servidor web Apache 5.1 Instalando el servidor web apache 5.2 Archivos de configuracin del servidor web Apache 5.2.1 Configuracin del fichero httpd.conf 5.3 Iniciar , detener o reiniciar el servidor web Apache 6 Creacin de dominios virtuales en Apache 6.1 Paso 1.- Activando la directiva NameVirtualHost 6.2 Paso 2.- Estructura de directorios para dominios virtuales 6.3 Paso 3.- Creacin y modificacin de los ficheros de configuracin de los dominios virtuales

Como empez todo#

El nombre del servidor web apache proviene de la palabra en ingles patchy server que en espaol se puede entender como servidor parchado, Tal vez te preguntaras, porque parchado?, la explicacin es sencilla, el servidor web apache fue conformado por diversos parches del servidor web usado en ese momento, nos referimos al servidor web NCSA el cual era desarrollado en ese entonces por el National Center Supercomputing. El desarrollo del servidor web apache se remonta al lejano ao de 1995, dicho desarrollo dio como resultado una especie de versin beta de lo que llegara a convertirse en la primera versin de apache ya que estaba compuesto en su totalidad por una coleccin de parches del servidor web NCSA. Fue hasta el ao de 1996 cuando fue lanzada la primera versin estable de Apache la cual tenia entre sus principales caractersticas la reescritura por completo de su cdigo base, tambin inclua la carga de mdulos en tiempo de ejecucin. Meses mas tarde fue lanzada la versin 1.1 la cual tenia como novedad la inclusin de un modulo de autenticacion contra bases de datos. La versin 1.3 de apache vio la luz en el ao de 1998 y esta inclua como principal caracterstica soporte para plataformas Windows. Actualmente el servidor web apache se encuentra en su versin 2 e incluye notables mejoras con respecto a versiones anteriores, algunas de ellas son: Modo Hbrido Nuevo sistema de configuracin y compilacin Soporte nativo para Ipv6 Mensajes de error en diferentes idiomas Mejoras adicionales.

Como dato adicional, cabe menciona que apache es el servidor web numero uno a nivel mundial el cual abarca cerca de un 52.26 % del mercado total de Internet desbancando a servidores web como el IIS (Internet Information Server) de Microsoft. Estos cifras pueden ser verificadas visitando el portal de Netcraft: http://news.netcraft.com/ Existe tambin una fundacin dedicada a dar soporte legal y financiero al desarrollo de los proyectos relacionados con Apache , el nombre de esta fundacin es Apache Software Foundation, la cual actualmente esta conformada por una comunidad de desarrolladores los cuales da a da contribuyen a la expansin y mejora de proyectos. Entre los proyectos mas destacados de esta fundacin podemos encontrar los siguientes:
Http Server.- Servidor Web Apache http://www.apache.org/ Jakarta.- Proyectos en el lado del servidor basados en Java

05/11/2011

Pgina 2 de 17

http://tomcat.apache.org/ mod_perl.- Modulo de apache para la programacin dinmica en Perl http://perl.apache.org/ SpamAssin.- Sistema de deteccin de Spam http://spamassassin.apache.org/

Proceso de instalacin del servidor web Apache#

Instalando el servidor web apache#
La instalacin del servidor web apache es relativamente sencilla , solo debe teclear en terminal el siguiente comando. [root@ localhost ~]# yum install -y httpd Recuerde que este comando se debe ejecutar como root

Archivos de configuracin del servidor web Apache#

La configuracin del servidor web apache se realizara sobre dos ficheros distintos, uno de configuracin general del servidor web apache y otro para indicarle al servidor apache los dominios virtuales que deben ser cargados al sistema. El fichero de configuracin principal de apache lo encontramos en la siguiente ruta: /etc/httpd/conf/ La carpeta donde debern ser aadidos los ficheros de configuracin de los dominios virtuales sera en la siguiente ruta: /etc/httpd/conf.d/

Configuracin del fichero httpd.conf#

La ubicacin de este fichero lo encontramos en: /etc/httpd/conf/ -----> httpd.conf

El contenido del fichero httpd.conf esta compuesto por un gran numero de secciones es por ello que solo describiremos las mas relevantes del mismo, usted podr habilitar o deshabilitar cada una de las funciones que describiremos segn su necesidad.

Directiva ServerTokens Esta directiva limita la cantidad de informacin que sera mostrada por nuestro servidor web apache como puede ser, la version del servidor web apache que tenemos instalado o los servicios que corren paralelamente con apache como php o MySQL. Para delimitar la cantidad de informacin mostrada por el sistema existen cuatro opciones:
ServerTokens ProductOnly Solo mostrara el nombre del servidor web instalado. Ejemplo: Server Apache ServerTokens Minimal Muestra el nombre asi como la version de apache instalada. Ejemplo: Server Apache 2.1 ServerTokens OS Mostrara el nombre, version y sistema operativo sobre el cual se encuentra montado:

Ejemplo: Server Apache 1.3/(Linux)

ServerTokens Full Mostrara nombre, version, sistema operativo asi como los servicios que hacen uso del servidor web. Ejemplo: Apache 1.3/(Linux)/PHP3/MySQL

Directiva ServerRoot

05/11/2011

Pgina 3 de 17

Esta directiva le indica al servidor web la ubicacin donde se almacenan los ficheros de configuracin de apache. El valor por defecto es:
ServerRoot /etc/httpd Si usted quisiera ubicar estos ficheros en otra ruta diferente solo deber especificarla, aunque no es recomendable

Directiva Timeout Esta directiva indica el nmero de segundos antes de que se cancele un conexin por falta de respuesta. Su valor por defecto es 120
Timeout 120

Directiva KeepAlive Esta directiva indica si se permiten o no las conexiones persistentes, es decir ms de una peticin por conexin. Puede tomar los valores de On u Off.
KeepAlive On|Off

Directiva MaxKeepAliveRequests Esta directiva indica el mximo nmero de peticiones que se permiten en conexiones persistentes. Un valor 0 permite un nmero ilimitado. Se recomienda dejar esta valor elevado para obtener un mayor rendimiento. Por ejemplo100
MaxKeepAliveRequests 100

Directiva KeepAliveTimeout Esta directiva indica el nmero de segundos de espera para la siguiente peticin del mismo cliente con la misma conexin. Por ejemplo 15
KeepAliveTimeout 15

Directiva Listen Listen permite asociar Apache a una direccin y/o puerto especfico adems del predeterminado. Ejemplo:
Listen 192.168.1.1:8080 Listen 80

Directiva Include
Include conf.d/*.conf Esta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros de configuracin adicionales de apache como por ejemplo los dominios virtuales. Es habitual dejar el fichero de configuracin con las caractersticas globales que no se tienen que modificar en el fichero principal e incluir los ficheros que pueden estar sujetos a modificacin en el directorio /etc/httpd/conf.d De esta forma para aadir o quitar algn fichero de configuracin de apache slo tenemos que borrarlo del directorio /etc/httpd/conf.d

Directiva LoadModule

05/11/2011

Pgina 4 de 17

Esta directiva corresponde al soporte de Dynamic Shared Object (Objetos Dinmicos Compartidos). Son mdulos que incorporan ciertas funcionalidades que se le incorporan al servidor Apache. Para que un mdulo sea funcional tienen que estar construido como un DSO e incorporar la correspondiente directiva `LoadModule' antes de que se a utilizada. Los mdulos compilados de forma esttica no es necesario incluirlos. Ejemplo:
LoadModule LoadModule LoadModule LoadModule LoadModule auth_basic_module modules/mod_auth_basic.so auth_digest_module modules/mod_auth_digest.so authn_file_module modules/mod_authn_file.so authn_alias_module modules/mod_authn_alias.so authn_anon_module modules/mod_authn_anon.so

Directiva User Esta directiva especifica qu usuario es el que ejecuta los procesos del servidor web y en consecuencia los permisos de lectura y escritura que se aplican sobre los recursos.
User apache

Directiva Group Esta directiva especifica qu grupo es el que ejecuta los procesos del servidor web y en consecuencia los permisos de lectura y escritura que se aplican sobre los recursos.
Group apache

Directiva ServerAdmin Esta directiva especifica la persona a la que se le debe notificar los problemas referentes al portal web , esto a travs de su cuenta de correo. Ejemplo:
ServerAdmin administrador@tuDominio.net

Directiva ServerName Esta directiva especifica el nombre y puerto que el servidor utiliza para identificarse. Con una correcta configuracin, este valor se puede determinar automticamente, pero es recomendable especificarlo explciatamente para evitar problemas durante el arranque.
ServerName www.tuDominio.net:80

Directiva UseCanonicalName UseCanonicalName determina como Apache construye las autoreferencias de URL y las variables SERVER_NAME y SERVER_PORT. Cuando est directiva esta como "Off" apache usa los valores suministrados por el cliente. Cuando est como "On" , apache usa la directiva ServerName. UseCanonicalName On|Off Directiva DocumentRoot Esta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros web de tu sitio principal
DocumentRoot "/var/www/html"

05/11/2011

Pgina 5 de 17

NOTA:Esta directiva cambia cuando se implementan sitios virtuales

Directiva Options La directiva Options indica varias posibles opciones de comportamiento y estas pueden ser aplicadas a un directorio concreto. Un claro ejemplo de aplicacin de estas directiva se puede observar en el siguiente cuadro:
Directory /web/docs> Options Indexes FollowSymLinks </Directory> <Directory /web/docs/spec> Options Includes </Directory>

Las opciones que podemos observar se explican con mas detalle en el siguiente cuadro:
All ExecCGI FollowSymLinks Includes Indexes MultiViews Todas las opciones salvo MultiViews Se permite la ejecucin de scripts CGI El servidor seguir los enlaces simblicos. Tener esta opcin activa aumenta el rendimiento ya que el servidor no comprueba si un fichero o directorio es un enlace simblico y es ms rpido, pero en algunos casos puede presentar problemas de inseguridad. Se permiten incluir Server-side. Si una URL solicita un directorio y no existe DirectoryIndex (v.g., index.html) en ese directorio, el servidor devolver una lista del contenido del directorio. Se permite mostrar contenido negociado en funcin de diversos valores.

SymLinksIfOwnerMatchSe sigue un enlace simblico slo si los propietarios del enlace y del destino coinciden.

Directiva AllowOverride La directiva AllowOverride controla qu directivas se pueden situar el los ficheros .htaccess y estas pueden ser aplicadas igualmente a un directorio concreto. Un claro ejemplo de aplicacin de estas directiva se puede observar en el siguiente cuadro:
<Directory "/var/www/icons"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> Los valores de AllowOverride pueden ser "All", "None", o una combinacin de: Permitir el uso de directivas de autorizacin (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc). Permitir el uso de directivas de control de tipo de documentos (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, etc). Permitir el uso de directivas que controlan los ndices de directorios (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc). Permitir el uso de directivas de acceso de hosts (Allow, Deny y Order). Permitir el uso de las opciones antes vistas en la directiva Options

AuthConfig FileInfo Indexes Limit Options

Directiva Allow La directiva Allow indica al sistema los equipos que pueden acceder a una determinada rea del servidor. El acceso se puede controlar por nombre, IP, rango de IP, igualmente pueden ser aplicadas a un directorio concreto. El primer argumento de esta directiva es siempre "from". Los siguientes argumentos pueden tener diferentes formas: All permite el acceso a todos los equipos excepto los especificados en Deny y

05/11/2011

Pgina 6 de 17

Order que se ver ms adelante. Para permitir el acceso a un dominio en especifico solo se deber especificar el antes mencionado Ejemplo:
Allow from linuxparatodos.net Tambin puede aplicarse esa misma regla usando direcciones IP Ejemplo: Allow from 207.249.24.61

Directiva Deny La directiva Deny indica al sistema los equipos que no podrn acceder al servidor web. El acceso se puede controlar por nombre, IP, rango de IP, igualmente pueden ser aplicadas a un directorio concreto El primer argumento de esta directiva es siempre "from". Los siguientes argumentos pueden tener diferentes formas: Para denegar el acceso a un dominio en especifico solo se deber especificar el antes mencionado Ejemplo:
Deny from microsoft.com Tambin puede aplicarse esa misma regla usando direcciones IP Ejemplo: Allow from 207.249.0.60

Directiva Order Esta directiva trabaja en conjunto con las dos directivas anteriores asi mismo se encarga de controlar el orden en que se ejecutan las antes descritas. Igualmente pueden ser aplicadas a un directorio concreto Ejemplo 1:
Order Deny,Allow En este ejemplo se evalu primero Deny, de esta forma se permite el acceso a cualquier equipo que no este listado en Deny, de esta forma el acceso se garantiza por defecto. Ejemplo 2: Order Allow,Deny En este ejemplo se evalu primero Allow, de esta forma se niega el acceso a cualquier equipo que no este listado en Allow, de esta forma el acceso se niega por defecto.

Directiva Alias La directiva Alias permite alojar ficheros fuera del directorio especificado en DocumentRoot , igualmente pueden ser aplicadas a un directorio concreto. La sintaxis necesaria para aplicar la directiva Alias es la siguiente:
Alias directorioAlternativo /vaw/www/manual Ejemplo Alias /home/gerencia /var/www/gerencia

Directiva ErrorLog ErrorLog indica la ubicacin del fichero de registro de errores en las consultas. Es conveniente especificar un fichero de registro en cada VirtualHost con el nombre asociado a ese servidor. De esta forma podemos separar los registros de los distintos dominios que tengamos albergados en el servidor web. Ejemplo:
ErrorLog logs/error_log

05/11/2011

Pgina 7 de 17

Directiva ErrorLevel LogLevel Controla el nmero de mensajes registrados en error_log. Puede ser: debug, info, notice, warn, error, crit, alert, emerg. Directiva Redirect La directiva Redirect permite indicar al cliente que un documento ha sido modificado o actualizado. Ejemplo:
Redirect permanent /portal1 ] [http://www.ies-bezmiliana/portal2

Iniciar , detener o reiniciar el servidor web Apache#

Para iniciar el servidor FTP por primera vez solo deber teclear en terminal el siguiente comando: [root@ localhost ~]# /etc/init.d/httpd start Igualmente existen opciones ya sea para reiniciar, detener, recargar o conocer el status en el que se encuentra el servidor FTP. Estas opciones pueden ser consultadas en la siguiente tabla: start stop restart Inicia el servicio Detiene el servicio Reinicia el servicio.-La diferencia con reload radica en que al ejecutar un restart este mata todos los procesos relacionado con el servicio y los vuelve a generar de nueva cuenta

Recarga el servicio.-La diferencia con restart radica en que al ejecutar un reload este solamente carga las actualizaciones hechas al fichero de configuracin del servicio sin necesidad de matar los procesos relacionados con el mismo, por lo que podra entenderse que hace el cambio en caliente. condrestartReinicio Condicional.- Solamente se inicia si el servicio se encuentra ejecutndose. reload status Da a conocer el estado en el que se encuentra el servicio Como alternativa tambin podemos ocupar el siguiente comando para iniciar el servidor FTP [root@ localhost ~]# service httpd start Y de igual manera podemos usar las opciones antes descritas en la tabla anterior. Recuerde que estos comandos se ejecutan como root.

Creacin de dominios virtuales en Apache#

La creacin de dominios virtuales sobre un servidor web como apache tiene una vital importancia cuando se trata de dar hospedaje a varios sitios web dentro del mismo servidor. Lograr implementar de manera correcta los dominios virtuales sobre el servidor web apache es tarea sencilla por lo que le recomendamos primero haber ledo todas las directivas que pueden ser aplicadas al fichero httpd.conf A partir de este punto comenzaremos a crear los dominios virtuales, es por ello que pedimos tu total concentracin y paciencia para que leas poco a poco estos puntos.

Paso 1.- Activando la directiva NameVirtualHost#

El primer paso sera abrir el fichero httpd.conf el cual esta almacenado en la ruta: /etc/httpd/conf/ En dicho fichero debemos localizar la siguiente linea y descomentarla si es que lo esta NameVirtualHost *:80

05/11/2011

Pgina 8 de 17

La funcin de esta directiva sirve para indicar la direccin IP en la que se esta brindando el servicio o bien insertando un asterisco(*) para que est activa en cualquier interfaz del servidor que es como nosotros lo debemos tener.

Paso 2.- Estructura de directorios para dominios virtuales #

Lo siguiente sera crear la estructura que contendr cada uno de los dominios virtuales que sern hospedados en nuestro servidor. Ejemplo: Suponga que tenemos 5 nombres de dominio que sern hospedados en nuestro servidor web www.turbolinux.com.mx www.comerciolinux.com www.escuelalinux.edu www.linuxunido.org www.linuxbloger.net por cada dominio se deber crear un directorio, dicho directorio sera nombrado de la misma forma que el dominio, solo omitiendo el www. [root@ [root@ [root@ [root@ [root@ localhost localhost localhost localhost localhost ~]# ~]# ~]# ~]# ~]# mkdir mkdir mkdir mkdir mkdir turbolinux.com.mx comerciolinux.com escuelalinux.edu linuxunido.org linuxbloger.net

Estos directorios debern ser creados dentro de la ruta /var/www/ Al final estos directorios debern quedar de la siguiente manera /var/www/turbolinux.com.mx /var/www/comerciolinux.com /var/www/escuelalinux.edu /var/www/linuxunido.org /var/www/linuxbloger.net Si no estn en la ruta antes descrita solo debe moverlos con el comando mv Lo siguiente sera crear dentro de cada uno de estos directorios la estructura bsica que debe llevar cada uno de estos dominios. Esta estructura estar conformada por cuatro directorios: html cgi-bin icons error

por lo que deber crear estos cuatro directorios para cada uno de los directorios de dominio. Ejemplo para el dominio turbolinux.com.mx
# # # # mkdir mkdir mkdir mkdir /var/www/turbolinux.com.mx/html /var/www/turbolinux.com.mx/cgi-bin /var/www/turbolinux.com.mx/icons /var/www/turbolinux.com.mx/error

y asi para los siguientes restantes dominios.

Paso 3.- Creacin y modificacin de los ficheros de configuracin de los dominios virtuales #
Una vez creadas las carpetas de dominios asi como tambin la estructura de cada uno pasaremos al ultimo paso, crear los ficheros de configuracin correspondientes a cada dominio. Nuevamente por cada dominio se deber crear un fichero de configuracin, dicho fichero sera nombrado de la misma forma que el dominio, solo omitiendo el www. [root@ [root@ [root@ [root@ [root@ localhost localhost localhost localhost localhost ~]# ~]# ~]# ~]# ~]# mkdir mkdir mkdir mkdir mkdir turbolinux.com.mx.conf comerciolinux.com.conf escuelalinux.edu.conf linuxunido.org.conf linuxbloger.net.conf

Estos directorios debern ser creados dentro de la ruta

05/11/2011

Pgina 9 de 17

/etc/httpd/conf.d/ Al final estos directorios debern quedar de la siguiente manera

Como empez todo#

El nombre del servidor web apache proviene de la palabra en ingles patchy server que en espaol se puede entender como servidor parchado, Tal vez te preguntaras, porque parchado?, la explicacin es sencilla, el servidor web apache fue conformado por diversos parches del servidor web usado en ese momento, nos referimos al servidor web NCSA el cual era desarrollado en ese entonces por el National Center Supercomputing. El desarrollo del servidor web apache se remonta al lejano ao de 1995, dicho desarrollo dio como resultado una especie de versin beta de lo que llegara a convertirse en la primera versin de apache ya que estaba compuesto en su totalidad por una coleccin de parches del servidor web NCSA. Fue hasta el ao de 1996 cuando fue lanzada la primera versin estable de Apache la cual tenia entre sus principales caractersticas la reescritura por completo de su cdigo base, tambin inclua la carga de mdulos en tiempo de ejecucin. Meses mas tarde fue lanzada la versin 1.1 la cual tenia como novedad la inclusin de un modulo de autenticacion contra bases de datos. La versin 1.3 de apache vio la luz en el ao de 1998 y esta inclua como principal caracterstica soporte para plataformas Windows. Actualmente el servidor web apache se encuentra en su versin 2 e incluye notables mejoras con respecto a versiones anteriores, algunas de ellas son: Modo Hbrido Nuevo sistema de configuracin y compilacin Soporte nativo para Ipv6 Mensajes de error en diferentes idiomas Mejoras adicionales.

Como dato adicional, cabe menciona que apache es el servidor web numero uno a nivel mundial el cual abarca cerca de un 52.26 % del mercado total de Internet desbancando a servidores web como el IIS (Internet Information Server) de Microsoft. Estos cifras pueden ser verificadas visitando el portal de Netcraft: http://news.netcraft.com/ Existe tambin una fundacin dedicada a dar soporte legal y financiero al desarrollo de los proyectos relacionados con Apache , el nombre de esta fundacin es Apache Software Foundation, la cual actualmente esta conformada por una comunidad de desarrolladores los cuales da a da contribuyen a la expansin y mejora de proyectos. Entre los proyectos mas destacados de esta fundacin podemos encontrar los siguientes:
Http Server.- Servidor Web Apache http://www.apache.org/ Jakarta.- Proyectos en el lado del servidor basados en Java http://tomcat.apache.org/ mod_perl.- Modulo de apache para la programacin dinmica en Perl http://perl.apache.org/ SpamAssin.- Sistema de deteccin de Spam http://spamassassin.apache.org/

Proceso de instalacin del servidor web Apache#

Instalando el servidor web apache#
La instalacin del servidor web apache es relativamente sencilla , solo debe teclear en terminal el siguiente comando. [root@ localhost ~]# yum install -y httpd Recuerde que este comando se debe ejecutar como root

05/11/2011

Pgina 10 de 17

Archivos de configuracin del servidor web Apache#

La configuracin del servidor web apache se realizara sobre dos ficheros distintos, uno de configuracin general del servidor web apache y otro para indicarle al servidor apache los dominios virtuales que deben ser cargados al sistema. El fichero de configuracin principal de apache lo encontramos en la siguiente ruta: /etc/httpd/conf/ La carpeta donde debern ser aadidos los ficheros de configuracin de los dominios virtuales sera en la siguiente ruta: /etc/httpd/conf.d/

Configuracin del fichero httpd.conf#

La ubicacin de este fichero lo encontramos en: /etc/httpd/conf/ -----> httpd.conf

El contenido del fichero httpd.conf esta compuesto por un gran numero de secciones es por ello que solo describiremos las mas relevantes del mismo, usted podr habilitar o deshabilitar cada una de las funciones que describiremos segn su necesidad.

Directiva ServerTokens Esta directiva limita la cantidad de informacin que sera mostrada por nuestro servidor web apache como puede ser, la version del servidor web apache que tenemos instalado o los servicios que corren paralelamente con apache como php o MySQL. Para delimitar la cantidad de informacin mostrada por el sistema existen cuatro opciones:
ServerTokens ProductOnly Solo mostrara el nombre del servidor web instalado. Ejemplo: Server Apache ServerTokens Minimal Muestra el nombre asi como la version de apache instalada. Ejemplo: Server Apache 2.1 ServerTokens OS Mostrara el nombre, version y sistema operativo sobre el cual se encuentra montado:

Ejemplo: Server Apache 1.3/(Linux)

ServerTokens Full Mostrara nombre, version, sistema operativo asi como los servicios que hacen uso del servidor web. Ejemplo: Apache 1.3/(Linux)/PHP3/MySQL

Directiva ServerRoot Esta directiva le indica al servidor web la ubicacin donde se almacenan los ficheros de configuracin de apache. El valor por defecto es:
ServerRoot /etc/httpd Si usted quisiera ubicar estos ficheros en otra ruta diferente solo deber especificarla, aunque no es recomendable

Directiva Timeout Esta directiva indica el nmero de segundos antes de que se cancele un conexin por falta de respuesta. Su valor por defecto es 120
Timeout 120

Directiva KeepAlive

05/11/2011

Pgina 11 de 17

Esta directiva indica si se permiten o no las conexiones persistentes, es decir ms de una peticin por conexin. Puede tomar los valores de On u Off.
KeepAlive On|Off

Directiva MaxKeepAliveRequests Esta directiva indica el mximo nmero de peticiones que se permiten en conexiones persistentes. Un valor 0 permite un nmero ilimitado. Se recomienda dejar esta valor elevado para obtener un mayor rendimiento. Por ejemplo100
MaxKeepAliveRequests 100

Directiva KeepAliveTimeout Esta directiva indica el nmero de segundos de espera para la siguiente peticin del mismo cliente con la misma conexin. Por ejemplo 15
KeepAliveTimeout 15

Directiva Listen Listen permite asociar Apache a una direccin y/o puerto especfico adems del predeterminado. Ejemplo:
Listen 192.168.1.1:8080 Listen 80

Directiva Include
Include conf.d/*.conf Esta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros de configuracin adicionales de apache como por ejemplo los dominios virtuales. Es habitual dejar el fichero de configuracin con las caractersticas globales que no se tienen que modificar en el fichero principal e incluir los ficheros que pueden estar sujetos a modificacin en el directorio /etc/httpd/conf.d De esta forma para aadir o quitar algn fichero de configuracin de apache slo tenemos que borrarlo del directorio /etc/httpd/conf.d

Directiva LoadModule Esta directiva corresponde al soporte de Dynamic Shared Object (Objetos Dinmicos Compartidos). Son mdulos que incorporan ciertas funcionalidades que se le incorporan al servidor Apache. Para que un mdulo sea funcional tienen que estar construido como un DSO e incorporar la correspondiente directiva `LoadModule' antes de que se a utilizada. Los mdulos compilados de forma esttica no es necesario incluirlos. Ejemplo:
LoadModule LoadModule LoadModule LoadModule LoadModule auth_basic_module modules/mod_auth_basic.so auth_digest_module modules/mod_auth_digest.so authn_file_module modules/mod_authn_file.so authn_alias_module modules/mod_authn_alias.so authn_anon_module modules/mod_authn_anon.so

Directiva User

05/11/2011

Pgina 12 de 17

Esta directiva especifica qu usuario es el que ejecuta los procesos del servidor web y en consecuencia los permisos de lectura y escritura que se aplican sobre los recursos.
User apache

Directiva Group Esta directiva especifica qu grupo es el que ejecuta los procesos del servidor web y en consecuencia los permisos de lectura y escritura que se aplican sobre los recursos.
Group apache

Directiva ServerAdmin Esta directiva especifica la persona a la que se le debe notificar los problemas referentes al portal web , esto a travs de su cuenta de correo. Ejemplo:
ServerAdmin administrador@tuDominio.net

Directiva ServerName Esta directiva especifica el nombre y puerto que el servidor utiliza para identificarse. Con una correcta configuracin, este valor se puede determinar automticamente, pero es recomendable especificarlo explciatamente para evitar problemas durante el arranque.
ServerName www.tuDominio.net:80

Directiva UseCanonicalName UseCanonicalName determina como Apache construye las autoreferencias de URL y las variables SERVER_NAME y SERVER_PORT. Cuando est directiva esta como "Off" apache usa los valores suministrados por el cliente. Cuando est como "On" , apache usa la directiva ServerName. UseCanonicalName On|Off Directiva DocumentRoot Esta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros web de tu sitio principal
DocumentRoot "/var/www/html" NOTA:Esta directiva cambia cuando se implementan sitios virtuales

Directiva Options La directiva Options indica varias posibles opciones de comportamiento y estas pueden ser aplicadas a un directorio concreto. Un claro ejemplo de aplicacin de estas directiva se puede observar en el siguiente cuadro:
Directory /web/docs> Options Indexes FollowSymLinks </Directory> <Directory /web/docs/spec> Options Includes </Directory>

05/11/2011

Pgina 13 de 17

Las opciones que podemos observar se explican con mas detalle en el siguiente cuadro:
All ExecCGI FollowSymLinks Includes Indexes MultiViews Todas las opciones salvo MultiViews Se permite la ejecucin de scripts CGI El servidor seguir los enlaces simblicos. Tener esta opcin activa aumenta el rendimiento ya que el servidor no comprueba si un fichero o directorio es un enlace simblico y es ms rpido, pero en algunos casos puede presentar problemas de inseguridad. Se permiten incluir Server-side. Si una URL solicita un directorio y no existe DirectoryIndex (v.g., index.html) en ese directorio, el servidor devolver una lista del contenido del directorio. Se permite mostrar contenido negociado en funcin de diversos valores.

SymLinksIfOwnerMatchSe sigue un enlace simblico slo si los propietarios del enlace y del destino coinciden.

Directiva AllowOverride La directiva AllowOverride controla qu directivas se pueden situar el los ficheros .htaccess y estas pueden ser aplicadas igualmente a un directorio concreto. Un claro ejemplo de aplicacin de estas directiva se puede observar en el siguiente cuadro:
<Directory "/var/www/icons"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> Los valores de AllowOverride pueden ser "All", "None", o una combinacin de: Permitir el uso de directivas de autorizacin (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc). Permitir el uso de directivas de control de tipo de documentos (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, etc). Permitir el uso de directivas que controlan los ndices de directorios (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc). Permitir el uso de directivas de acceso de hosts (Allow, Deny y Order). Permitir el uso de las opciones antes vistas en la directiva Options

AuthConfig FileInfo Indexes Limit Options

Directiva Allow La directiva Allow indica al sistema los equipos que pueden acceder a una determinada rea del servidor. El acceso se puede controlar por nombre, IP, rango de IP, igualmente pueden ser aplicadas a un directorio concreto. El primer argumento de esta directiva es siempre "from". Los siguientes argumentos pueden tener diferentes formas: All permite el acceso a todos los equipos excepto los especificados en Deny y Order que se ver ms adelante. Para permitir el acceso a un dominio en especifico solo se deber especificar el antes mencionado Ejemplo:
Allow from linuxparatodos.net Tambin puede aplicarse esa misma regla usando direcciones IP Ejemplo: Allow from 207.249.24.61

Directiva Deny La directiva Deny indica al sistema los equipos que no podrn acceder al servidor web. El acceso se puede controlar por nombre, IP, rango de IP, igualmente pueden ser aplicadas a un directorio concreto El primer argumento de esta directiva es siempre "from". Los siguientes argumentos pueden tener diferentes formas: Para denegar el acceso a un dominio en especifico solo se deber especificar el antes mencionado Ejemplo:

05/11/2011

Pgina 14 de 17

Deny from microsoft.com Tambin puede aplicarse esa misma regla usando direcciones IP Ejemplo: Allow from 207.249.0.60

Directiva Order Esta directiva trabaja en conjunto con las dos directivas anteriores asi mismo se encarga de controlar el orden en que se ejecutan las antes descritas. Igualmente pueden ser aplicadas a un directorio concreto Ejemplo 1:
Order Deny,Allow En este ejemplo se evalu primero Deny, de esta forma se permite el acceso a cualquier equipo que no este listado en Deny, de esta forma el acceso se garantiza por defecto. Ejemplo 2: Order Allow,Deny En este ejemplo se evalu primero Allow, de esta forma se niega el acceso a cualquier equipo que no este listado en Allow, de esta forma el acceso se niega por defecto.

Directiva Alias La directiva Alias permite alojar ficheros fuera del directorio especificado en DocumentRoot , igualmente pueden ser aplicadas a un directorio concreto. La sintaxis necesaria para aplicar la directiva Alias es la siguiente:
Alias directorioAlternativo /vaw/www/manual Ejemplo Alias /home/gerencia /var/www/gerencia

Directiva ErrorLog ErrorLog indica la ubicacin del fichero de registro de errores en las consultas. Es conveniente especificar un fichero de registro en cada VirtualHost con el nombre asociado a ese servidor. De esta forma podemos separar los registros de los distintos dominios que tengamos albergados en el servidor web. Ejemplo:
ErrorLog logs/error_log

Directiva ErrorLevel LogLevel Controla el nmero de mensajes registrados en error_log. Puede ser: debug, info, notice, warn, error, crit, alert, emerg. Directiva Redirect La directiva Redirect permite indicar al cliente que un documento ha sido modificado o actualizado. Ejemplo:
Redirect permanent /portal1 ] [http://www.ies-bezmiliana/portal2

05/11/2011

Pgina 15 de 17

Iniciar , detener o reiniciar el servidor web Apache#

Para iniciar el servidor FTP por primera vez solo deber teclear en terminal el siguiente comando: [root@ localhost ~]# /etc/init.d/httpd start Igualmente existen opciones ya sea para reiniciar, detener, recargar o conocer el status en el que se encuentra el servidor FTP. Estas opciones pueden ser consultadas en la siguiente tabla: start stop restart Inicia el servicio Detiene el servicio Reinicia el servicio.-La diferencia con reload radica en que al ejecutar un restart este mata todos los procesos relacionado con el servicio y los vuelve a generar de nueva cuenta

Recarga el servicio.-La diferencia con restart radica en que al ejecutar un reload este solamente carga las actualizaciones hechas al fichero de configuracin del servicio sin necesidad de matar los procesos relacionados con el mismo, por lo que podra entenderse que hace el cambio en caliente. condrestartReinicio Condicional.- Solamente se inicia si el servicio se encuentra ejecutndose. reload status Da a conocer el estado en el que se encuentra el servicio Como alternativa tambin podemos ocupar el siguiente comando para iniciar el servidor FTP [root@ localhost ~]# service httpd start Y de igual manera podemos usar las opciones antes descritas en la tabla anterior. Recuerde que estos comandos se ejecutan como root.

Creacin de dominios virtuales en Apache#

La creacin de dominios virtuales sobre un servidor web como apache tiene una vital importancia cuando se trata de dar hospedaje a varios sitios web dentro del mismo servidor. Lograr implementar de manera correcta los dominios virtuales sobre el servidor web apache es tarea sencilla por lo que le recomendamos primero haber ledo todas las directivas que pueden ser aplicadas al fichero httpd.conf A partir de este punto comenzaremos a crear los dominios virtuales, es por ello que pedimos tu total concentracin y paciencia para que leas poco a poco estos puntos.

Paso 1.- Activando la directiva NameVirtualHost#

El primer paso sera abrir el fichero httpd.conf el cual esta almacenado en la ruta: /etc/httpd/conf/ En dicho fichero debemos localizar la siguiente linea y descomentarla si es que lo esta NameVirtualHost *:80 La funcin de esta directiva sirve para indicar la direccin IP en la que se esta brindando el servicio o bien insertando un asterisco(*) para que est activa en cualquier interfaz del servidor que es como nosotros lo debemos tener.

Paso 2.- Estructura de directorios para dominios virtuales #

Lo siguiente sera crear la estructura que contendr cada uno de los dominios virtuales que sern hospedados en nuestro servidor. Ejemplo: Suponga que tenemos 5 nombres de dominio que sern hospedados en nuestro servidor web www.turbolinux.com.mx www.comerciolinux.com www.escuelalinux.edu www.linuxunido.org www.linuxbloger.net por cada dominio se deber crear un directorio, dicho directorio sera nombrado de la misma forma que el dominio, solo omitiendo el www.

05/11/2011

Pgina 16 de 17

[root@ [root@ [root@ [root@ [root@

localhost localhost localhost localhost localhost

~]# ~]# ~]# ~]# ~]#

mkdir mkdir mkdir mkdir mkdir

turbolinux.com.mx comerciolinux.com escuelalinux.edu linuxunido.org linuxbloger.net

Estos directorios debern ser creados dentro de la ruta /var/www/ Al final estos directorios debern quedar de la siguiente manera /var/www/turbolinux.com.mx /var/www/comerciolinux.com /var/www/escuelalinux.edu /var/www/linuxunido.org /var/www/linuxbloger.net Si no estn en la ruta antes descrita solo debe moverlos con el comando mv Lo siguiente sera crear dentro de cada uno de estos directorios la estructura bsica que debe llevar cada uno de estos dominios. Esta estructura estar conformada por cuatro directorios: html cgi-bin icons error

por lo que deber crear estos cuatro directorios para cada uno de los directorios de dominio. Ejemplo para el dominio turbolinux.com.mx
# # # # mkdir mkdir mkdir mkdir /var/www/turbolinux.com.mx/html /var/www/turbolinux.com.mx/cgi-bin /var/www/turbolinux.com.mx/icons /var/www/turbolinux.com.mx/error

y asi para los siguientes restantes dominios.

Paso 3.- Creacin y modificacin de los ficheros de configuracin de los dominios virtuales #
Una vez creadas las carpetas de dominios asi como tambin la estructura de cada uno pasaremos al ultimo paso, crear los ficheros de configuracin correspondientes a cada dominio. Nuevamente por cada dominio se deber crear un fichero de configuracin, dicho fichero sera nombrado de la misma forma que el dominio, solo omitiendo el www. [root@ [root@ [root@ [root@ [root@ localhost localhost localhost localhost localhost ~]# ~]# ~]# ~]# ~]# mkdir mkdir mkdir mkdir mkdir turbolinux.com.mx.conf comerciolinux.com.conf escuelalinux.edu.conf linuxunido.org.conf linuxbloger.net.conf

Estos directorios debern ser creados dentro de la ruta /etc/httpd/conf.d/ Al final estos directorios debern quedar de la siguiente manera /etc/httpd/conf.d/turbolinux.com.mx.conf /etc/httpd/conf.d/comerciolinux.com.conf /etc/httpd/conf.d/escuelalinux.edu.conf /etc/httpd/conf.d/linuxunido.org.conf /etc/httpd/conf.d/linuxbloger.net.conf Si no estn en la ruta antes descrita solo debe moverlos con el comando mv. Lo siguiente sera crear dentro de cada uno de estos ficheros la estructura bsica que deben contener para que puedan ser ledos por el fichero principal de configuracin de apache, nos referimos al fichero httpd.conf. Esta estructura estar conformada por la siguiente configuracin bsica: Ejemplo de configuracin para el dominio turbolinux.com.mx

05/11/2011

Pgina 17 de 17

<VirtualHost *:80> ServerAdmin administrador@tuDominio.net DocumentRoot "/var/www/turbolinux.com.mx/html" ServerName www. turbolinux.com.mx ServerAlias turbolinux.com.mx </VirtualHost> Los parmetros usados son descritos en la siguiente tabla: La funcin de esta directiva sirve para indicar la direccin IP en la que se esta brindando o bien insertando un asterisco(*) para que est activa en cualquier interfaz del servidor que es como nosotros lo debemos tener. Esta directiva especifica la persona a la que se le debe notificar los problemas referentes al portal web , esto a travs de su cuenta de correo.

VirtualHost ServerAdmin

DocumentRoot Esta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros web de tu sitio principal. Esta directiva especifica el nombre y puerto que el servidor utiliza para identificarse. Con una correcta configuracin, este ServerName valor se puede determinar automticamente, pero es recomendable especificarlo explciatamente para evitar problemas durante el arranque. ServerAlias Esta directiva sirve para que el mismo sitio web sea accesible desde distintos nombres de dominio. Ejemplo: turbolinux.com.mx ---> www.turbolinux.com.mx

/etc/httpd/conf.d/turbolinux.com.mx.conf /etc/httpd/conf.d/comerciolinux.com.conf /etc/httpd/conf.d/escuelalinux.edu.conf /etc/httpd/conf.d/linuxunido.org.conf /etc/httpd/conf.d/linuxbloger.net.conf Si no estn en la ruta antes descrita solo debe moverlos con el comando mv. Lo siguiente sera crear dentro de cada uno de estos ficheros la estructura bsica que deben contener para que puedan ser ledos por el fichero principal de configuracin de apache, nos referimos al fichero httpd.conf. Esta estructura estar conformada por la siguiente configuracin bsica: Ejemplo de configuracin para el dominio turbolinux.com.mx <VirtualHost *:80> ServerAdmin administrador@tuDominio.net DocumentRoot "/var/www/turbolinux.com.mx/html" ServerName www. turbolinux.com.mx ServerAlias turbolinux.com.mx </VirtualHost> Los parmetros usados son descritos en la siguiente tabla: La funcin de esta directiva sirve para indicar la direccin IP en la que se esta brindando o bien insertando un asterisco(*) para que est activa en cualquier interfaz del servidor que es como nosotros lo debemos tener. Esta directiva especifica la persona a la que se le debe notificar los problemas referentes al portal web , esto a travs de su cuenta de correo.

VirtualHost ServerAdmin

DocumentRoot Esta directiva indica al servidor web la ruta en donde se encuentran almacenados los ficheros web de tu sitio principal. Esta directiva especifica el nombre y puerto que el servidor utiliza para identificarse. Con una correcta configuracin, este ServerName valor se puede determinar automticamente, pero es recomendable especificarlo explciatamente para evitar problemas durante el arranque. ServerAlias Esta directiva sirve para que el mismo sitio web sea accesible desde distintos nombres de dominio. Ejemplo: turbolinux.com.mx ---> www.turbolinux.com.mx 15571 Accesos

0 archivos adjuntos

Promedio (0 Votos)

Comentarios

05/11/2011

Use MySQL Replication Like an Expert to Improve Performance and Enhance Availability
Posted by Anatoliy A. Dimitrov on Mon, Oct 10, 20112

By using MySQL replication, you can distribute MySQL queries over multiple servers to improve application performance, provide high availability (HA), and distribute data across diverse physical locations. The process involves one or more master servers, which send databases or tables asynchronously to slave servers. For all of its potential benefits, MySQL replication can cause serious trouble, especially in complex environments. Follow the advice here to get off to a healthy start. In MySQL replication each participating server may be a master, a slave, or both. Master servers handle database transactions and write them to a binary log (binlog). Slaves connect to masters and request copies of their binary logs. Servers can act both as master and slave thanks to features such as different auto increment, which sets the interval between successive column values. Theoretically, it is possible to have more than two masters. In such cases MySQL replicates changes in a circle. However, it is very hard to maintain and troubleshoot such circular replication. When the replication breaks (and such interruptions are unavoidable in the long term) it's hard to ensure the integrity of the information and resume fast operation with all the data. MySQL's developers recommend using no more than two masters. The number of MySQL slaves is not a concern, because slaves cannot make global changes and cannot cause deployment-wide problems.

A Replication Alternative Distributed Replicated Block Device (DRBD) replication is a non-MySQL-specific replication alternative. It copies the underlying block device that stores the MySQL data files. Block device-level replication is officially supported in the Linux kernel, so it can be used for replicating files for different applications. In DRBD replication, there is always only one master, though this master can be dynamically changed through another service, such as Heartbeat, in case of failure. DRBD replication is suitable for highavailability solutions.

Replicated MySQL data represents a statement that is successfully executed on the master and recorded to its binlog, and is a statement that makes a change, such as insert, update, or delete. Select statements are not logged in the binlog nor replicated unless they invoke stored functions that make changes. MySQL replication works in two modes. Commonly, statement-based updates are sent to slaves in the form of the original queries. Since version 5.1 MySQL also supports row-based replication, in which the master(s) informs the slave(s) which rows were affected and how they have been changed. This mode is considered more reliable because alerts appear even if a single row fails to be updated.

Simple Master/Slave Replication

The simplest MySQL replication involves a single master/slave relationship between two servers. In this case the master MySQL configuration file (/etc/my.cnf by default) should include the following values:

[mysqld] log_bin = master-binlog server-id = 1

These directives instruct MySQL to write its data-changing queries to the binlog file /var/log/mysq/master-binlog.XXX under a default Linux configuration, where XXX is a sequential number for previous binlog files. This file's events will be sent to the slave server. server-id distinguishes the server from which the queries come. You must also create on the master server a MySQL user with privileges to get a dump of the binary log from the master:

master> CREATE USER replication_user; master> GRANT REPLICATION SLAVE ON *.* TO replication_user IDENTIFIED BY 'secret_password';

Next it's time to configure the replication on the slave server from its MySQL console:

slave> CHANGE MASTER TO MASTER_HOST='ipaddr_of_slave_server', MASTER_USER='replication_user',MASTER_PASSWORD='secret_password';

You can then start slave replication by executing start slave. To ensure it is running correctly, execute show slave status on the slave server and ensure there are no errors in Last_Error column. If you see any errors you must resolve them before you can get replication working. This oversimplified example shows how easy it is to get basic MySQL replication started. Complex problems are not likely to appear in such a simple master/slave relation, but real-life scenarios may cause significant headaches, as we will see in a moment.

Scaling Out for Better Performance

Some of the most common problems MySQL administrators face are slowness and locked tables. Complex searches and updates can decrease performance and even cause downtime when an application's wait timeout exceeds the time for which a table is still locked from a previous query. Of course, if you have a capital budget, you can scale-up your hardware with more RAM and faster CPUs, but the problems are not likely to disappear. That's why another strategy is usually preferred: MySQL scale-out through replication. With this strategy, complex and resource-heavy select statements can be outsourced to slave servers, where they will not cause overhead to the main MySQL servers. Thanks to replication, the data on the slave servers mirrors that of the master(s). This technique is especially useful for generating regular reports or performing searches on big data. Meanwhile, heavy update and replace statements can be performed on other master servers sometimes. It can help only when row-based replication is used and the number of updates rows is little; otherwise, it will send a large amount of

data, which will cause overhead too. Thus this technique can be a life-saver when complex statements compare values from millions of rows in order to update just a few. For simple update statements on numerous rows, row-based replication will cause more overhead, because it has to send all the rows to each slave instead of just a single command. A general rule is that MySQL replication always adds a little bit of overhead to the master server, and it's definitely not a universal scale-out solution. The best solution is first to try optimizing the application's code for faster MySQL queries, but this is not always feasible. In order not to increase queries' execution times, replication implementation has to be carefully designed.

A High Availability Strategy

MySQL replication plays an essential role in avoiding unplanned downtime and ensuring data integrity during and after failover and failback. Recovery and failback requires a reliable, two-way MySQL replication strategy, usually in the form of master/master replication. In master/master replication, each of two servers is both a master and a slave to the other. To ensure that values in auto increment columns don't overlap from different servers, master/master replication uses a different offset margin on each server. Replication with two masters is a relatively safe and proven technique with one unique advantage that comes when you have to execute resource-intensive commands to change data, as happens for example when you alter the structure of large tables or update a large number of rows. These kinds of changes are usually associated with application updates. In such cases, under normal circumstances, tables will be locked and unavailable to applications, resulting in downtime. However, with a dual-master replication scheme, you can create a downtime-free scenario:
o o

Stop replication in either direction. On the inactive (second) master, execute SET SESSION SQL_LOG_BIN=0 to ensure that statements in the current session are not logged in the binlog, nor replicated. Then execute the necessary

commands on it. When you're done, enable logging again with SET SESSION SQL_LOG_BIN=1.
o

After the changes take effect, switch the application to work with the recently updated second master. On the first master, repeat the steps you followed on the inactive master: stop logging, execute commands, and reenable logging. Once you've completed all manual updates, start the replication again. Optionally switch the application to work again with the first master.

Many third-party solutions can enhance MySQL replication for HA and ease the burden of managing MySQL replication during failover and failback. Some are MySQL proxies such as MySQL proxy and GreenSQL; others are complete solutions, such as Tungsten replicator.

Replication Problems and Troubleshooting

When working with MySQL replication, try to follow the KISS principle: Keep it simple, stupid! MySQL's powerful and extensive replication capabilities can be dangerous to your data's integrity. Even in the best case, with the simplest slave, master replication problems may render your reports inaccurate. It's relatively easy to fix such problems (as we will see shortly) or even start a new slave. But imagine a more complex case with load balancing and multiple masters. When the replication between the masters breaks, as it inevitably will, and load balancing continues working, corresponding (or even the same) records on different servers will have different values, even though you have configured the offset options correctly. For example, imagine a customer makes a purchase at an online store. A record for the purchase is inserted correctly for the customer on one of the servers, but because of replication problems it is not replicated to the other server(s). When the client refreshes she may not see the purchase if her query is executed on a server with broken slave replication. The customer may decide to try purchasing the same item again, causing another record to be created. It's uncertain on which server this record will be created, but in any case it will be a problem later. Now imagine a

busy store that handles a large number of purchases in the interval the business needs to fix the replication. Such a bad scenario can lead to refunds and chargebacks, and ruin a store's reputation. When replication breaks you can see the exact error by running show slave status on the problematic server's MySQL console. The error will be in the column Last_Error in the result. One common error says, "Could not parse relay log event entry." This error indicates that the relay log file at the slave server is corrupted. This is usually caused by filesystem problems or lack of free space. To fix it, execute on the slave server show slave status and write down the values from the columns Exec_Master_Log_Pos as X and Master_Log_File as Y. Go to the master server and use mysqlbinlog to dump the statements from Master_Log_File into a text file. Open the newly created text file and search for the previously found value X. Write down the next position (pos value) as Z, the value to use as the place to restart the replication from. Finally, on the slave server run change master to master_log_file='Y',master_log_pos=Z, substituting Y and Z with your values. You may also see errors when a command cannot be executed on the slave server. The nature of such errors may vary greatly, from breaking constraints (foreign keys) to schema incompatibilities (different tables' structures). First you must address the reason for the error in order to preserve data consistency and integrity between the servers. You may decide that the command can be ignored; even though this is highly unrecommended it can be useful for temporary or noncritical data. In such cases there is a dirty trick to skip the failed statement: stop replication, execute on the slave server SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1, and start replication again. You can also ignore errors with same type number permanently by adding slave-skiperrors=number_of_error to your MySQL configuration file. This is rarely a good idea, but MySQL provides such an option. You can use it if you want to restore replication fast and plan to fix the errors later. MySQL replication is an extremely useful tool for implementing high availability and improving scalability. It is a complex and powerful tool, however, and has to be managed carefully.

MySQL Proxy learns R/W Splitting

August 01, 2007
The trunk version of the MySQL Proxy 0.6.0 just learnt about changing backends within running connection. It is now up to lua-script to decide which backend shall be used to send requests too. We wrote a complete tutorial which covers everything from:

building and maintaining a connection pool with high and low water marks transparent authentication (no extra auth against the proxy) deciding on Query Level which backend to use

and implement a transparent read/write splitter which sends all non-transactional Queries to the slaves and the rest to the master.

As the splitting is in the hands of the lua-scripting level you can use the same to implement sharding or other rules to route traffic on statement level.

Connection Pooling
For R/W Splitting we need a connection pooling. We only switch to another backend if we already have a authenticated connection open to that backend. The MySQL protocol first does a challenge-response handshake. When we enter the query/result stage it is too late to authenticate new connections. We have to make sure that we have enough open connections to operate nicely.

In the keepalive tutorial we spend quite some code on connection management. The whole connect_servers() function is only to create new connections for all pools. 1. create one connection to each backend 2. create new connections until we reach min-idle-connections 3. if the two above conditions are met, use a connection from the pool Lets take a glimpse at the code:
config connectionpool localmin_idle_connections=4 localmax_idle_connections=8 getaconnectiontoabackend aslongaswedon'thaveenoughconnectionsinthepool,createnewconnections functionconnect_server() makesurethatweconnecttoeachbackendatleastonesto keeptheconnectionstotheserversalive onread_querywecanswitchthebackendsagaintoanotherbackend localleast_idle_conns_ndx=0 localleast_idle_conns=0 fori=1,#proxy.serversdo locals=proxy.servers[i]

ifs.state~=proxy.BACKEND_STATE_DOWNthen trytoconnecttoeachbackendonceatleast ifs.idling_connections==0then proxy.connection.backend_ndx=i return end trytoopenatleastmin_idle_connections ifleast_idle_conns_ndx==0or (s.idling_connections<min_idle_connectionsand s.idling_connections<least_idle_conns)then least_idle_conns_ndx=i least_idle_conns=s.idling_connections end end end ifleast_idle_conns_ndx>0then proxy.connection.backend_ndx=least_idle_conns_ndx end ifproxy.connection.backend_ndx>0and proxy.servers[proxy.connection.backend_ndx].idling_connections>=min_idle_connectio nsthen wehave4idlingconnectionsinthepool,that'sgoodenough returnproxy.PROXY_IGNORE_RESULT end

openanewconnection end

The real trick is in

puttheauthedconnectionintotheconnectionpool functionread_auth_result(packet) disconnectfromtheserver proxy.connection.backend_ndx=0 end

The proxy.connection.backend_ndx = 0 we disconnect us from the current backend (lua starts indexing at index 1, 0 is out of bounds). If a second connection comes in now it can use this authed connection too as it is in the pool, idling. By setting proxy.connection.backend_ndx you control which backend is used to send your packets too. A backend is defined as a entry of the proxy.servers table. Each connection has (zero or) one backend. The backends all have a address, a type (RW or RO) and a state (UP or DOWN). As we also might have to many open connections in the pool we close them on shutdown again if necessary:
closetheconnectionsifwehaveenoughconnectionsinthepool @returnnilcloseconnection IGNORE_RESULTstoreconnectioninthepool functiondisconnect_client() ifproxy.connection.backend_ndx==0then currentlywedon'thaveaserverbackendassigned pickaserverwhichhastoomanyidlingconnectionsandcloseone fori=1,#proxy.serversdo locals=proxy.servers[i]

ifs.state~=proxy.BACKEND_STATE_DOWNand s.idling_connections>max_idle_connectionsthen trytodisconnectabackend proxy.connection.backend_ndx=i return end end end end

We only search for a backend which has to many open idling connections and use it before we enter the default behaviour of disconnect_client: shutdown the server connection. if
proxy.connection.backend_ndx==0then is the we dont have backend associated right now.

We already saw this in read_auth_result .

Read/Write Splitting
That is our maintainance of the pool. connect_server() adds new authed connections to the pool, disconnect_client() closes them again. The read/write splitting is part of the query/result cycle:
read/writesplitting functionread_query(packet) ifpacket:byte()==proxy.COM_QUITthen don'tsendCOM_QUITtothebackend.Wemanagetheconnection inallaspects. proxy.response={ type=proxy.MYSQLD_PACKET_ERR, errmsg="ignoredtheCOM_QUIT" } returnproxy.PROXY_SEND_RESULT end

asweswitchbetweendifferentconnenctionswehavetomakesurethat weusealwaysthesameDB ifpacket:byte()==proxy.COM_INIT_DBthen default_dbisconnectionglobal default_db=packet:sub(2) end ifproxy.connection.backend_ndx==0then wedon'thaveabackendrightnow let'spickamasterasagooddefault fori=1,#proxy.serversdo locals=proxy.servers[i] ifs.idling_connections>0and s.state~=proxy.BACKEND_STATE_DOWNand s.type==proxy.BACKEND_TYPE_RWthen proxy.connection.backend_ndx=i break end end end ifpacket:byte()==proxy.COM_QUERYanddefault_dbthen howcanIknowthedboftheserverconnection? proxy.queries:append(2,string.char(proxy.COM_INIT_DB)..default_db) end proxy.queries:append(1,packet)

Up to now it is only making sure that we behave nicely:

dont forward COM_QUIT to the backend as he will close the connection on us intercept the COM_INIT_DB to know which DB the client wants to work on. If we switch to another backend we have to make sure the same DB is used.

The read/write splitting is now following a simple rule:

send all non-transactional SELECTs to a slave everything else goes to the master

We are still in read_query()

read/writesplitting sendallnontransactionalSELECTstoaslave ifis_in_transaction==0and packet:byte()==proxy.COM_QUERYand packet:sub(2,7)=="SELECT"then localmax_conns=1 localmax_conns_ndx=0 fori=1,#proxy.serversdo locals=proxy.servers[i] pickaslavewhichhassomeidlingconnections ifs.type==proxy.BACKEND_TYPE_ROand s.idling_connections>0then ifmax_conns==1or s.connected_clients<max_connsthen max_conns=s.connected_clients max_conns_ndx=i end end end

 wefoundaslavewhichhasaidlingconnection ifmax_conns_ndx>0then proxy.connection.backend_ndx=max_conns_ndx end else sendtomaster end returnproxy.PROXY_SEND_QUERY end

If we found a slave host which has a idling connection we pick it. If all slaves are busy or down, we just send the query to the master. As soon as we dont need this connection anymore give it backend to the pool:
aslongasweareinatransactionkeeptheconnection otherwisereleaseitsoanotherclientcanuseit functionread_query_result(inj) localres=assert(inj.resultset) localflags=res.flags ifinj.id~=1then ignoretheresultoftheUSE<default_db> returnproxy.PROXY_IGNORE_RESULT end is_in_transaction=flags.in_trans ifis_in_transaction==0then releasethebackend

proxy.connection.backend_ndx=0 end end

The MySQL Protocol is nice and offers us a in-transaction-flag. This operates on the state of the transaction and works across all engines. If you want to make sure that several statements go to the same backend, open a transaction with BEGIN. No matter which storage engine you use.

Possible extensions
While we are here in this section of the code think about another use case:

if the master is down, ban all writing queries and only allow reading selects against the slaves.

It keeps your site up and running even if your master is gone. You only have to handle errors on write-statements and transactions.

Known Problems
We might have a race-condition that idling connection closes before we can use it. In that case we are in trouble right now and will close the connection to the client. We have to add queuing of connections and awaking them up when the connection becomes available again to handle this later.

Next Steps
Testing, testing, testing.
$mysqlproxy\ proxybackendaddresses=10.0.0.1:3306\ proxyreadonlybackendaddresses=10.0.0.10:3306\ proxyreadonlybackendaddresses=10.0.0.12:3306\ proxyluascript=examples/tutorialkeepalive.lua

The above code works for my tests, but I dont have any real load. Nor can I create all the error-cases you have in your real-life setups. Please send all your comments, concerns and ideas to the MySQL Proxy forum.

Another upcoming step is externalizing all the load-balancer code and move it into modules to make the code easier to understand and reuseable. mysql-proxy