Soporte técnico

Soporte técnico

Descubre lo que nos diferencia

Preguntas frecuentes Manuales para VPS y dedicados

Existen muchas y diversas formas de instalar un servidor LAMP, dependiendo sobre todo de las necesidades particulares de cada caso, desde el sistema operativo escojido, hasta los módulos que vams a necesitar a posteriori. LAMP son las siglas de Linux, Apache, MySQL y PHP, por lo que para instalarlo nos podemos basar en cualquiera de las diferentes versiones de Linux, pero en nuestro caso nos hemos decidido en hacerlo sobre una instalación limpia y minimalista de CentOS.

 Instalar Apache

Lo primero que debemos hacer es instalar elmotor Web, en nuestro caso Apache.

yum install httpd httpd-devel
En un futuro podemos necesitar instalar o compilar otras librerias, por ello instalamos tambien las bibliotecas de desarrollo.


Lo siguiente que debemos hacer es iniciar el servicio de Apache (hhtpd)

service httpd start
Instalar MySQL

En este paso instalaremos y configuraremos el motor de base de datos MySQL.

yum install mysql mysql-server mysql-devel
También instalamos las bibliotecas de desarrollo por si nos hacen falta en un futuro.


Ahora arrancamos el servicio de MySQL (mysqld)

service mysqld start
Lo primero que debemos hacer para configurar MySQL es cambiar la contraseña del root (administrador) que por defecto se encuentra en blanco. Si no lo hacemos podemos encontrarnos con un gran problema de seguridad. Para ello debemos ingresar primero en la consola de MySQL.
mysql

Dentro de la consola seguiremos los siguientes pasos. Donde sustituiremos ('newpassword') por ('mi_password').

mysql> USE mysql;
mysql> UPDATE user SET Password=PASSWORD('newpassword') WHERE user='root';
mysql> FLUSH PRIVILEGES;
mysql> exit

Comprobaremos que hemos seguido los pasos correctamente y podemos entrar con nuestra nueva contraseña.

mysql -u root -p
Enter Password: <tu nueva contraseña>

Si lo hemos hecho correctamente volveremos a tener el simbolo de consola mysql> y podemos escribir exit para salir.

Instalar PHP5

Lo último que debemos de instalar es PHP5 y sus módulos para que se enlacen correctamente con Apache y MySQL.

yum install php php-mysql php-common php-gd php-mbstring php-mcrypt php-devel php-xml
Al igual que en las anteriores instalaciones, tambien instalamos las bibliotecas de desarrollo. También instalamos ciertos componentes que son imprescindibles ya sea para enlazar PHP5 con MySQL, como para interpretar XML o trabajar con gráficos.

Ahora debemos de reiniciar el servicio de Apache (httpd) de nuevo, para que de esta forma Apache sea capaz de interpretar correctamente el lenguaje PHP.

service httpd restart

Si hemos seguido todos los pasos correctamente ya tenemos nuestro servidor LAMP preparado para funcionar.

Probar la Instalación

Para comprobar la instalación y de que esta funcionando correctamente debemos seguir los siguientes pasos.

cd /var/www/html

Este es el directorio raiz de los documentos de Apache. Es decir aqui debemos empezar a subir nuestras páginas web.

Creamos un nuevo archivo, al que podemos llamar test.php y que podemos dejar allí para comprobar la configuración de PHP5. 

vi test.php

E introducimos el siguiente texto en el archivo.

<?php phpinfo(); ?>

Ahora solo nos queda abrir nuestro navegador favorito y teclear http://ip_servidor_lamp/test.php

Esto nos mostrará la información de PHP5, variables, límites de memoria y archivos, etc.

Entramos en consola y nos logueamos como root (ponemos su y luego la contraseña de root). 
Luego simplemente, copiar y pegar lo siguiente: 

aptitude update && aptitude safe-upgrade && aptitude full-upgrade && aptitude clean && aptitude autoclean 

Listo, con esto deberíamos tener el sistema actualizado y bastante limpio. Para algunos si leen por ahí que el comando "aptitude full-upgrade" es muy "agresivo" (aunque yo lo uso siempre y no me da problemas) simplemente editen los comandos para que les quede así: 

aptitude update && aptitude safe-upgrade && aptitude clean && aptitude autoclean
 

Un apunte mas: cada tanto, al instalar y desinstalar programas, yo hago un 

aptitude -f install o aptitude install -f (es lo mismo) 

Esto lo hago para ver si Debian sugiere instalar algún programa o bien que detecte algún paquete que está roto y sugiere instalar algún complemento al mismo. 
Pero atención: si les pasa que al ejecutar esto les pide instalar nuevamente paquetes desinstalados por Uds. y no quieren volver a hacerlo, simplemente hacen: 

aptitude keep-all 
aptitude --autoclean 

Al ejecutar este último comando los va a mandar a otra ventana, simplemente dan "enter" cuando les da la opción de "aceptar", luego oprimen "q" y finalmente click en "yes". 
Ahora volvemos a poner en consola 

aptitude -f install 

Y listo, no nos debería pedir actualizar, eliminar o reinstalar nada si el sistema está limpio. 

En esta sencilla guía vamos a ver cómo instalar ConfigServer Security & Firewall (CSF), un paquete de aplicaciones para Linux que incluye in firewall ampliamente configurable y herramientas para análisis de logs y detección de intrusiones. Además se integra como plugin a DirectAdmin, y chequea distintos items de la configuración del servidor para darnos ideas sobre cuestiones a mejorar.

La instalación es muy sencilla.

cd /usr/src
wget http://www.configserver.com/free/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Cuando lo probé yo me dio un error indicando que necesitaba el módulo LWP de Perl, el cual instalé con CPAN.

cpan -i LWP

Por último, es importante correr las pruebas que vienen incluidas para ver si tenemos todos los módulos de iptables necesarios. Aquí lo importante es que no dé FATAL ERRORS.

perl /etc/csf/csftest.pl

Eso es todo. Ahora ingresamos como admin a Directadmin, y en la sección de plugins encontraremos a ConfigServer. Allí podemos cambiar la configuración del firewall. Una vez terminado de configurar, cuando estamos seguros que todo funciona, debemos deshabilitar el testing mode. Este último lo que hace es limpiar el iptables regularmente, por si nos equivocamos, para no quedarnos sin acceder al servidor. También desde aquí podemos pedirle a ConfigServer que ejecute sus pruebas para ver la seguridad del servidor, y nos indique qué puntos nos quedan asegurar.

Créditos:

  • Tail-F.com.ar

En esta pequeña guía veremos cómo actualizar muy sencillamente el software de nuestro servidor Directadmin usando Custombuild. Ya en otro artículo habíamos visto lo sencillo que era instalar software con Custombuild. En esta oportunidad, veremos que es igual de sencillo utilizarlo para mantener nuestro software actualizado.

Lo primero que debemos hacer es un update para descargar las nuevas versiones de las aplicaciones:

# cd /usr/local/directadmin/custombuild
# ./build update

Ahora que tenemos actualizado el propio custombuild, verificadas las versiones locales del software y descargadas las actualizaciones, podemos ver qué podemos actualizar.

# ./build versions

Esto nos va a mostrar por cada uno de los programas y librerías que maneja Custombuild, qué versión tenemos instalada y si hay una nueva para instalar. En base a esta lista, lo que podemos hacer es instalar la actualización para un programa/librería en particular, o actualizar todo.

Por ejemplo, si queremos actualizar solamente Apache, usaremos:

# ./build httpd

En cambio, si queremos actualizar todo, ejecutaremos:

# ./build update_versions

El Cron

Custombuild permite instalar un cronjob para manejar las actualizaciones. Tiene dos funcionalidades: avisarnos por mail cuando hay actualizaciones y actualizar automáticamente el software. Esto se configura en el archivo options.conf de Custombuild.

#Cron settings
cron=yes
email=nuestroemail@dominio.com
notifications=yes
updates=no

La variable “cron” habilita/deshabilita el cronjob. Si lo queremos instalar tiene que estar en “yes”. La variable “email” es la dirección donde recibiremos las notificaciones. Luego “notifications” habilita/deshabilita las notificaciones por email y “updates” habilita/deshabilita la actualización automática.

Personalmente, recomiendo no activar las actualizaciones automáticas, pues puede generar problemas inesperados en momentos en que no podemos resolverlos. Es preferible hacerlas manualmente cuando lo consideremos adecuado. Por otro lado, el cron se ocupa de actualizar automáticamente las aplicaciones web (los webmails), lo cual no suele traer problemas.

Para instalar el cron debemos configurar las opciones mencionadas en el options.conf (indicando cron=yes) y luego ejecutar:

# ./build cron

Créditos:

  • Tail-F.com.ar

Directadmin utiliza el sistema de quotas del sistema operativo para calcular el espacio que está siendo utilizado por cada usuario. A veces, por diversas circunstancias, puede ser que necesitemos recalcular estos datos. Particularmente, en estos días tuvimos un problema con el acceso a un dispositivo que generó problemas en la ejecución del comando repquota y cuando solucioné el problema, tuve que recalcular la quota de todos los usuarios del sistema. Me pareció que sería útil explicar cómo hacerlo, porque si bien es algo que está explicado en la Knowledge Base de Directadmin, allí está en inglés.

Para que el sistema recalcule las quotas, es decir, analice todo el filesystem verificando el uso del disco y cree, confirme o repare los archivos de quotas, necesitamos correr el comando quotacheck. Para ello necesitamos deshabilitar las quotas, chequear y volver a habilitarlas.

# /sbin/quotaoff -a
# /sbin/quotacheck -avugm
# /sbin/quotaon -a

Esto tomará algunos minutos (particularmente el proceso quotacheck). Luego de lo cual podemos esperar que Directadmin corra el tally y recalcule los valores para cada usuario, o podemos indicarle explícitamente que lo haga en este momento. Para ello debemos agregar la tarea del tally a la cola:

# echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

El tally se ejecutará cuando corra el proceso dataskq de Directadmin (que se ejecuta cada minuto). Podemos ver los logs de este proceso en /var/log/directadmin/system.log.

Pero si somos demasiado impacientes o queremos ver información de debug, podemos correr explícitamente el dataskq.

# /usr/local/directadmin/dataskq d10

Listo. Una vez que Directadmin re-procese todos los usuarios, los datos de consumo de disco de cada uno se habrá sincronizado con la información actual del sistema.

Créditos:

  • Tail-F.com.ar

¿Qué es un proxy inverso?

Un proxy inverso en este caso es, básicamente, un servidor web que se interpone como una capa entre el cliente y un backend, de manera de optimizar la conexión. Típicamente el proxy es un servidor muy liviano que funciona de frontend, atiende las peticiones de los clientes HTTP y deriva el procesamiento en un backend que podría ser un servidor Apache. Según la configuración que apliquemos, un proxy nos permite introducir mayor seguridad en nuestra red, hacer balanceo de carga, hacer cache, etc.

También optimiza el manejo de memoria. Pensemos que Apache lanza un thread o proceso por cada nuevo cliente, el cual se cierra recién cuando termina la transferencia de datos. Si el cliente tiene una conexión lenta, por más que Apache funcione rápido, el proceso queda corriendo hasta que se terminen de enviar los datos. Un frontend liviano como Nginx nos permite que el proceso que espere al cliente sea mucho más liviano que uno de Apache.

Por último, como indican en sysadmin.es, un proxy Nginx nos sirve para prevenir ataques de denegación de servicio utilizando slowloris.

Un proxy inverso en un servidor de hosting

Los proxies se suelen utilizar en arquitecturas para servir sitios de alta demanda. En esos casos es común, por ejemplo, hacer que Apache sirva el contenido dinámico y un servidor más liviano (lighttpd o nginx) sirva contenido estático. Pero en un servidor de hosting esto no es tan sencillo, pues al alojarse varios sitios en un mismo equipo nuestra configuración debe ser lo más genérica posible para que sirva a la mayor parte de nuestros clientes. Como veremos, podemos definir algún tipo de cache, pero también tiene que ser bastante genérico para no causar problemas. Además tenemos que pensar en la integración con el panel de control que estemos usando. Yo uso Directadmin y este panel no tiene (aún) una integración nativa con otro web server que no sea Apache.

Nginx + Apache + Directadmin

La opción que les presento es para utilizar Nginx como proxy inverso, manejando las conexiones de los clientes y haciendo un muy básico cache del contenido estático. La guía está pensada para CentOS, pero en otros sistemas operativos no debería ser muy distinto.

Primero instalamos Nginx. El proceso es muy sencillo.

# cd /usr/src
# wget http://nginx.org/download/nginx-0.7.67.tar.gz
# tar zxvf nginx-0.7.67.tar.gz
# cd nginx-0.7.67
# ./configure --prefix=/usr \
              --conf-path=/etc/nginx/nginx.conf \
              --error-log-path=/var/log/nginx/error.log \
              --http-log-path=/var/log/nginx/access.log \
              --pid-path=/var/run/nginx/nginx.pid \
              --lock-path=/var/run/nginx/nginx.lock \
              --with-http_stub_status_module \
              --with-openssl=/usr/lib/openssl
# make && make install

Creamos el directorio para guardar el cache de contenido estático:

# mkdir -p /var/tmp/nginx
# chown apache:apache /var/tmp/nginx

Lo más importante es configurar Nginx. Para ello modificaremos /etc/nginx/nginx.conf para que quede algo similar a esto:

Importante: reemplazar __SERVER_IP__ por la IP del servidor y __SERVER_HOSTNAME__ por el nombre del servidor.

user  apache;
worker_processes  1;

events {
    worker_connections  8192;
}

http {
    server_tokens off;

    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    tcp_nopush     on;

    keepalive_timeout  75 20;

    gzip  on;

    server_names_hash_bucket_size 64;
    reset_timedout_connection on;

    client_max_body_size 100m;

    # Main cache data
    proxy_cache_path  /var/tmp/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m;
    proxy_temp_path /var/tmp/nginx/proxy;
    proxy_connect_timeout 30;
    proxy_read_timeout 120;
    proxy_send_timeout 120;
    proxy_cache_key "$scheme$host$request_uri";

    server {
        listen       __SERVER_IP__:81;
        server_name  __SERVER_HOSTNAME__ _;

        #charset koi8-r;
        charset off;

        access_log off;
        #access_log  /var/log/nginx/access.log  main;

        # Main reverse proxy for most requests
        location / {
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                    proxy_pass              http://__SERVER_IP__;    # apache here

                    client_max_body_size       16m;
                    client_body_buffer_size    128k;

                    #proxy_buffering     off;
                    proxy_buffering     on;  

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         120;
                    proxy_buffer_size          8k;
                    proxy_buffers              32 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;

                    error_page              502 503 /50x.html;
        }

        # Proxy cache for static files
        location ~* \.(jpg|png|gif|jpeg|css|swf|mov|doc|pdf|xls)$ {
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                    proxy_pass              http://__SERVER_IP__;    # apache here

                    client_max_body_size       16m;
                    client_body_buffer_size    128k;

                    #proxy_buffering     off;
                    proxy_buffering     on;  

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         120;
                    proxy_buffer_size          8k;
                    proxy_buffers              32 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;

                    # Proxy cache data
                    proxy_cache_valid 200 120m;
                    expires 864000;
                    proxy_cache staticfilecache;

                    error_page              502 503 /50x.html;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /var/www/html;
        }

    }

}

Por supuesto esta es una configuración básica que debería adaptarse al caso específico. Es importante notar lo siguiente:

  • Nginx escucha en el puerto 81 y Apache en el 80. Esto es importante para no tener que hacer cambios en la configuración de Directadmin.
  • Se definen 3 Locations. Las primeras dos son proxies que le pasan requests al Apache esuchando en el puerto 80. La segunda aplica solamente a los requests de archivos estáticos y hace un cache en /var/tmp/nginx. Este cache es manejado siguiendo los headers HTTP correspondientes.

Ahora necesitamos instalar un módulo de Apache, mod_rpaf, para poder usar el header X-Real-IP.

# cd /usr/src
# wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
# tar zxvf mod_rpaf-0.6.tar.gz
# cd mod_rpaf-0.6
# apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

Y luego agregamos esto al httpd.conf

LoadModule rpaf_module /usr/lib/apache/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 __SERVER_IP__
RPAFheader X-Forwarded-For

Reemplazando __SERVER_IP__ por la IP del servidor.

También vamos a necesitar un script para el init del Nginx. Como no encontré uno hecho, hice este:

#!/bin/bash
#
# Name: NginX, tsj5j
#
# Function:     Start up NginX
#
# chkconfig: - 85 15
# description: NginX starter

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

prog="nginx"
nginx=/usr/sbin/nginx

start () {
        echo -n $"Starting $prog: "
        $nginx
        RETVAL=$?
        return $RETVAL
}

stop () {
        echo -n $"Stopping $prog: "
        killproc $nginx
        RETVAL=$?
        return $RETVAL
}

reload () {
        echo -n $"Reloading $prog: "
        killproc $nginx -HUP
        RETVAL=$?
        return $RETVAL
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        stop
        sleep 1
        start
        ;;
  reload)
        reload
        ;;
  graceful)
        reload
        ;;
esac

exit $RETVAL;

Una vez ubicado ese contenido en un archivo /etc/init.d/nginx lo habilitamos

# chkconfig --add nginx
# chkconfig nginx on
# service nginx start

Y nos falta una única cosa. Tenemos Apache corriendo en el puerto 80 y Nginx en el 81. ¿Cómo hacemos que Nginx atienda las peticiones de nuestros clientes? Creamos una ruta en iptables para que redirija el tráfico del puerto 81 al 80:

# iptables -t nat -A PREROUTING -p tcp -s ! _SRV_IP_ --dport 80 -j REDIRECT --to-ports 81
# service iptables save

Reemplazando __SERVER_IP__ por la IP del servidor.

Y listo, ahora nuestro Nginx va a recibir todo el tráfico HTTP y negociar con el Apache para devolverlo a los clientes.

Verificar que atienda Nginx

Comprobar que Nginx esté atendiendo las peticiones en el puerto 80 es muy sencillo de hacer con curl. Por ejemplo, probándolo contra la URL de este blog.

# curl -I http://www.tail-f.com.ar
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 18 Sep 2010 04:09:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Cookie,Accept-Encoding,User-Agent
X-Pingback: http://www.tail-f.com.ar/xmlrpc.php
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: no-cache

Como vemos el servidor que atiende es Nginx.

Créditos:

  • Tail-F.com.ar

Usualmente ejecutas mysqldump para exportar una base de datos, en sentencias SQL, de la siguiente forma:

$ mysqldump -u usuario -p base-de-datos > base-de-datos.sql

Luego copias el archivo base-de-datos.sql al servidor MySQL remoto usando sftp/ssh:

$ scp base-de-datos.sql usuario@servidor.remoto.com:/backup

Y restauras la base de dato en el servidor remoto, mediante SSH:

$ mysql -u usuario -p base-de-datos < base-de-datos.sql

O:

$ mysql -u usuario -p 'contraseña' base-de-datos < base-de-datos.sql

 

¿Como puedo copiar la base de datos desde un servidor a otro?

La respuesta rápida es que puedes copiar la base de datos de un servidor a otro usando el cliente SSH o el cliente MySQL.

Puedes ejecutar los anteriores comandos en uno solo usando mysqldump y mysql (metodo inseguro, usalo solo si estás en una VPN o red segura):

$ mysqldump db-name | mysql -h remote.box.com db-name

También puedes usar SSH si no tienes acceso remoto directo al servidor MySQL de destino (metodo seguro):

$ mysqldump db-name | ssh user@remote.box.com mysql db-name

O:

$ mysqldump -u username -p'password' db-name | ssh user@remote.box.com mysql -u username -p'password db-name

También puedes copiar una sola tabla al servidor remoto, por ejemplo la tabla "foo", usando el siguiente comando:

$ mysqldump db-name foo | ssh user@remote.box.com mysql bar

O:

$ mysqldump -u user -p'password' db-name foo | ssh user@remote.box.com mysql -u user -p'password' db-name foo

La mayoría de comandos UNIX/Linux se pueden encadenar usando tuberias (pipes), "|".

¿Como puedo actualizar CentOS a la última versión, a través de internet?
 
Las últimas versiones de CentOS incluyen actualizaciones importantes de seguridad y estabilidad, así como nuevos componentes y versiones del kernel de Linux. Es importante mantener siempre actualizado el servidor, para evitar posibles problemas de seguridad o intrusiones no deseadas.

La actualización del sistema es un proceso sencillo en CentOS, utilizando el gestor YUM.

 

Paso # 1: Crear un backup del servidor

Es importante crear un backup del servidor completo antes de ejecutar cualquier procedimiento. El backup debe almacenarse en un servidor diferente, de forma que pueda ser utilizado en caso de necesidad. La mayoria de los comandos aquí indicados requieren permisos de administrador (root) para ser ejecutados, generalmente utilizando bash o cualquier otra shell moderna.

 

Paso # 2: Actualizar todos los paquetes

Utiliza el siguiente comando para ver un listado completo de los paquetes que serán actualizados:

# yum list updates

Para proceder con la actualización, ejecuta:

# yum update

Reinicia el servidor:

# reboot

Verifica que todo está funcionando correctamente:

# uname -a
# netstat -tulpn
# tail -f /var/log/messages
# tail -f /path/to/log/file
# cat /etc/redhat-release

Ejemplo de respuesta:

CentOS release 5.4 (Final)

También puedes usar el comando lsb_release:

# lsb_release -a

Ejemplo de respuesta:

Distributor ID:	CentOS
Description:	CentOS release 5.4 (Final)
Release:		5.4
Codename:	Final

Para ver el log de todos los paquetes actualizados:

tail -f /var/log/yum.log
less /var/log/yum.log
grep -i bind /var/log/yum.log