Archivo del Autor: Julio Pons Terol

Acerca de Julio Pons Terol

Profesor de la ETSINF de la Universidad Politécnica de Valencia

Instalación de nginx como proxy de apache en centos 6 y virtualmin

En este artículo vamos a ver la instalación paso a paso de un servidor nginx para mejorar las prestaciones de nuestro servidor web apache.

El objetivo es que todas las peticiones las sirva el servidor nginx, de forma que el contenido estático lo servirá directamente mientras que el contenido dinámico (por ejemplo páginas php las solicitará al servidor apache y las servirá como un proxy).

Todo esto lo vamos a hacer sobre nuestro sistema centos 6.5 controlado por un panel virtualmin.

1. Instalación de nginx en centos 6.

Lo mejor para esta instalación es seguir las instrucciones de nginx.org (http://nginx.org/en/linux_packages.html#stable)

Descargamos e instalamos el package ngnix release:
# wget http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
# rpm -Uvh nginx-release-centos-6-0.el6.ngx.noarch.rpm

Ahora podemos instalar ngnix con yum, Primero verificamos que tenemos las últimas versiones estables con:
# yum list nginx

Available Packages
nginx.x86_64 1.4.5-1.el6.ngx

Instalamos:
# yum install nginx

A continuación vamos a instalar mod_rpaf, un módulo de apache que hace que interprete correctamente las direcciones que vienen de un proxy. (Referencia: http://www.ctkn.net/2011/10/install-mod_rpaf-on-centos-5-centos-6/)

Primero instalamos el paquete httpd-devel

# yum install httpd-devel

Ahora descargamos el paquete mod_rpaf

# cd /usr/local/src
# wget http://mirror.trouble-free.net/sources/mod_rpaf-0.6.tar.gz
# tar xzvf mod_rpaf-0.6.tar.gz
# cd mod_rpaf-0.6

Lo compilamos e instalamos con:

# apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

Ahora hemos de crear el archivo de configuración /etc/httpd/conf.d/mod_rpaf.conf

# vi /etc/httpd/conf.d/mod_rpaf.conf

con el siguiente contenido:

LoadModule rpaf_module modules/mod_rpaf-2.0.so
# mod_rpaf Configuration
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 xxx.xxx.xxx.xxx
RPAFheader X-Forwarded-For

Cambiando xxx,xxx,xxx,xxx por la IP de nuestro servidor (si tiene varias las podemos poner todas o por lo menos la que utilice de salida).

El siguiente paso es cambiar los puertos de escucha de apache del 80 al 9080 y del 443 al 9443 por ejemplo. La idea es dejar libres el puerto 80 y el 443 para el nginx y mantener el apache activo en puertos alternativos.

El archivo de configuración es /etc/httpd/conf/httpd.conf y las líneas donde aparecen los puertos son:

Listen 80 ==> Listen 9080
NameVirtualHost xxxxx:80 ==> NameVirtualHost xxxxx:9080
NameVirtualHost xxxxx:443 ==> NameVirtualHost xxxxx:9443

Hay que cambiar todas las líneas que tengan este formato. Además en el archivo /etc/httpd/conf/ssl.conf

Listen 443 ==> Listen 9443

Con esto cambiamos todas las webs que ya tengamos configuradas, ahora es necesario actualizar las plantillas para que cuando creemos nuevas web (servidores virtuales en la terminología de virtualmin) tengamos esto correctamente configurado.

Para ello vamos al interfaz de virtualmin –> System Settings –> Plantillas de Servidor

Y elegimos la plantilla «Default Settings» y vamos a la sección «Sitio web Apache»

En esta ventana tenemos que configurar los puertos de acceso:

Ahora en la seccion de «Rotación de archivos de bitácora» debemos incluir los archivos de log adicionales y un script para que reinicie adeuadamente los servidores después de la rotación. Debe quedar así:

La información que hay que poner es:

Directivas de logrotate para nuevos servidores:

 rotate 5
 weekly
 compress
 postrotate
 [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
 /etc/rc.d/init.d/httpd graceful ; sleep 5
 endscript
 sharedscripts

Additional files to rotate:

/var/log/virtualmin/${DOM}_apache_access_log
/var/log/virtualmin/${DOM}_nginx_error_log

Los archivos de log

Antes de seguir con las instrucciones de configuración vamos a comentar como hacer para que coexistan los archivos de log que generan los servidores web.

Tanto nginx como apache generan un archivo de log de accesos y otro de errores. Si utilizamos como ejemplo un dominio denominado xxxx.com el nombre del archivo de log que asigna virtualmin para apache es /var/log/virtualmin/xxxx.com_access_log y
/var/log/virtualmin/${DOM}_error_log respectivamente, y utiliza este nombre de archivo de acceso para configurar el software de estadísticas gráficas awstat y webalizer.

Sin embargo, puesto que nginx es el servidor web que recibe directamente toas las peticiones del exterior y a apache sólo le llegan algunas, esta configuración no es correcta y el software de estadísticas no tendrá toda la información.

Para resolver esto de forma sencilla, lo que vamos a hacer es crear el servidor virtual con virtualmin y dejarle que lo configure así, y luego editar manualmente el archivo de configuración de apache para que se llame  /var/log/virtualmin/xxxx.com_apache_access_log de forma que configuraremos nginx para que su archivo de log se llame  /var/log/virtualmin/xxxx.com_access_log (que es el que usará el software de estadísticas).

El archivo de error no es relevante para las estadísticas por lo que podemo dejarlo como lo configura virtualmin y el archivo de error de nginx le llamaremos /var/log/virtualmin/xxxx_nginx_error_log

Configuración de nginx

A continuación vamos a presentar los 3 archivos de configuración de nginx que necesitamos para que el sistema funcione. El primero es el archivo de configuración principal /etc/nginx/nginx.conf que ya viene preconfigurado, pero que vamos a modificar para activar la compresión web y algún parámetro adicional. La propuesta es:

user apache;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
 worker_connections 1024;
}

http {
 include /etc/nginx/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;
 tcp_nodelay on;

 gzip on;
 gzip_http_version 1.1;
 gzip_vary on;
 gzip_comp_level 6;
 gzip_proxied any;
 gzip_min_length 1100;
 gzip_buffers 4 32k;
 gzip_types text/plain text/css application/json application/javascript application/x-javascript text/javascript text/xml application/xml application/rss+xml application/atom+xml application/rdf+xml
 gzip_disable "MSIE [1-6]\.(?!.*SV1)";

 keepalive_timeout 65;

 include /etc/nginx/conf.d/*.conf;
}

El siguiente archivo lo creamos nosotros para especificar las características de la conexión proxy con el servidor apache y lo incluiremos posteriormente desde los archivos específicos de las webs. El archivo es /etc/nginx/proxy.conf y este es su contenido:

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 4G;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffers 32 4k;

Por último, por cada web que tengamos tenemos que crear un archivo de configuración en el directorio /etc/nginx/conf.d

A modo de ejemplo vamos a suponer que nuestro dominio es xxxx.com, que el directorio home es /home/xxxx y que la ip es aaa.bbb.ccc.ddd, además vamos a configurarlo para acceder por https y haremos que los accesos por http se redireccionen de forma automáticas a https. Es bastante fácil a partir de aquí hacer una versión sin https.

El archivo será /etc/nginx/conf.d/xxxx.com.conf y este es su contenido:

server {
 listen aaa.bbb.ccc.ddd:80;
 server_name www.xxxx.com xxxx.com;

 # Strict Transport Security
 add_header Strict-Transport-Security max-age=2592000;

 rewrite ^(.*) https://www.xxxx.com$1 permanent;
}

server {
 # server port and name
 listen aaa.bbb.ccc.ddd:443;
 server_name www.xxxx.com xxxx.com;
 client_max_body_size 4G;
 root /home/xxxx/public_html;

 # ssl certificate files
 ssl on;
 ssl_certificate /home/xxxx/ssl.cert;
 ssl_certificate_key /home/xxxx/ssl.key;

 # add ssl specific settings
 keepalive_timeout 60;

 # limit ciphers
 ssl_ciphers HIGH:!ADH:!MD5;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_prefer_server_ciphers on;

 access_log /var/log/virtualmin/xxxx.com_access_log;
 error_log /var/log/virtualmin/xxxx.com_nginx_error_log;

 location / {
 proxy_pass http://aaa.bbb.ccc.ddd:9080;
 include /etc/nginx/proxy.conf;
 }

 location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 break;
 }


 location ~* ^.+\.(js|jpeg|jpg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mp3|htm|html|xml)$ {
 expires 30d;
 root /home/xxxx/public_html;
 }

 location ~ /\.ht {
 deny all;
 }
}

Sólo necesitamos reiniciar nginx para tener la web funcionando:

# service nginx restart

Mejoras futuras

Añadir nuevas webs (servidores virtual) es incómodo ya que después de crear la web con el virtualmin hay que hacer bastantes modificaciones de forma manual. Lo ideal sería hacer que todo el proceso sea automático. En estos momentos tengo un Trabajo Fin de Grado en marcha para desarrollar esto.

Otra posibilidad es utilizar varnish como proxy en lugar de nginx (o en colaboración con nginx), aunque el mayor handicap de varnish es la ausencia de soporte para https. También tengo otro TFG sobre este tema.

También es interesante la posibilidad de personalización de los archivos de configuración de nginx para cada web y optimizarlo para las aplicaciones específicas de la web como por ejemplo wordpress o prestashop.

Referencias

Evitando un man in the middle en SSH

El punto crítico en la seguridad de SSH es en el momento de la primera conexión de un cliente con el servidor. Después de que el servidor envía su clave pública al cliente, el cliente puede compararla con la que tiene en su base de datos de hosts conocidos (know_hosts) para ver si estamos hablando con el servidor auténtico.

El problema es que hacer cuando no tenemos referencias del host al que nos estamos conectando, lo que ocurre cuando es la primera vez que nos conectamos.

Hay un parámetro en la configuración del cliente SSH (StrictHostKeyChecking) que indica como actuar en estos casos. Si utilizamos mobaxterm (http://mobaxterm.mobatek.net/) el archivo de configuración lo tenemos en /etc/ssh_config.

A StrictHostKeyChecking podemos darle 3 valores: yes, ask, no. En mobaxterm el valor predeterminado es no que significa que cuando se detecta una conexión a un nuevo host nos fiamos de él y automáticamente almacenamos su clave pública en la lista de hosts cononcidos.

Si le asignamos el valor si entonces el sistema no autorizará ningún acceso a hosts desconocidos.

Mi recomendación es poner ask que instruye al cliente ssh a que nos pregunte cuando se encuentre un host desconocido. En esa pregunta nos muestra una huella de la clave pública, que es algo así como esto:

fd:1f:02:8c:12:ce:d2:c4:c9:13:f9:e7:ae:92:2a:df

Ante dicha pregunta la acción correcta sería comparar la huella con la del servidor (que nos deberían haber haber facilitado junto a nuestros credenciales de login y password) y sólo si es idéntica proseguir con la conexión.

Puesto que este montón de dígitos es incómodo para hacer la comparación, hay una representación alternativa «semi-gráfica» de la huella que podemos decir a nuestro cliente ssh que nos genere y que también nos pueden facilitar junto con nuestros credenciales.

Para configurar el cliente ssh para que nos muestre la huella semi-gráfica hay que ir al archivo ssh_config y añadir la siguiente línea:

VisualHostKey yes

Una vez lo hemos configurado, cuando nos conectemos por primera vez al servidor ocurrirá algo como esto:

ssh [email protected]
The authenticity of host 'redescorporativas.es (37.187.22.136)' can't be established.
RSA key fingerprint is fd:1f:02:8c:12:ce:d2:c4:c9:13:f9:e7:ae:92:2a:df.
+--[ RSA 2048]----+
|      ..         |
|     o.o         |
|      B.         |
|     = o.+.      |
|    . = So+      |
|     . .  .o     |
|       . .  o .  |
|  .  .o   .  o . |
|   oo.E...    .  |
+-----------------+
Are you sure you want to continue connecting (yes/no)?

Verificaremos el huella y si es la correcta, podemos contestar «yes».

Como dato adicional indiacr que al tener la opción VisualHostKey yes, cada vez que nos conectemos al servidor nos mostrará la huella.

Puesto que esta solución no deja de ser manual, hay propuestas para intentar automatizar esto y que sea más cómodo para el usuario. Una de ellas consiste validad la huella por DNS, escribiendo en un registro especial del servidor de nombres del dominio la huella de forma que el cliente pueda comprobarlo de forma automática con una consulta al servidor DNS del dominio. Evidentemente en este caso es necesario recurrir a DNSSEC para evitar la posibilidad de otro man in the middle entre el cliente y el servidor DNS.

Ejemplo de Huella de un servidor SSH

Los servidores SSH envían a los clientes su clave pública. A partir de la clave pública se puede obtener una huella tanto en formato hexadecimal como en formato semi-gráfico.

Esta huella debería facilitarse por parte del servidor a los clientes para que pudieran verificar la primera vez que se conectan que nadie ha suplantado el servidor.

Esta información debería facilitarse al usuario junto con las claves de acceso o bien anunciarse en la página web del servidor (autenticada con certificado SSL).

A continuación os presento un ejemplo de la huella en formato hexadecimal y semigráfico.

fd:1f:02:8c:12:ce:d2:c4:c9:13:f9:e7:ae:92:2a:df

+--[ RSA 2048]----+
|      ..         |
|     o.o         |
|      B.         |
|     = o.+.      |
|    . = So+      |
|     . .  .o     |
|       . .  o .  |
|  .  .o   .  o . |
|   oo.E...    .  |
+-----------------+

Instalación de python 2.7.8 en centos 6.5

Centos 6.5 viene con el python 2.6.6 instalado, pero esta no es la última versión 2.X disponible. La última versión 2.X en estos momentos es la 2.7.8.

El problema es que Centos utiliza el python en muchas herramientas del sistema (como por ejemplo yum) y por tanto no podemos actualizar fácilmente sin introducir problemas en estas herramientas, por tanto la solución es instalar un segundo python alternativo sin sustituir al del sistema.

Esta guía está basada en el artículo How To Set Up Python 2.7.6 and 3.3.3 on CentOS 6.4.

Lo primero que tenemos que hacer es asegurarnos de que tenemos actualizados los paquetes de software de nuestros sistema. Accedemos como root y ejecutamos:

# yum update

Para instalar la última versión 2.X de python vamos a compilar desde las fuentes por lo que hemos de preparar el sistema para desarrollo:

# yum groupinstall -y development

En mi instalación esto implicó:

Install      65 Package(s)
Total download size: 59 M
Installed size: 188 M

# yum install -y zlib-devel openssl-devel sqlite-devel bzip2-devel

# yum install openssl-devel bzip2-devel expat-devel gdbm-devel

Ahora ya podemos descargar el python, utilizamos wget. Sería conveniente ir primero a www.python.org para ver cual es la última versión:

# wget https://www.python.org/ftp/python/2.7.8/Python-2.7.8.tar.xz

Y lo descomprimimos:

# xz -d Python-2.7.8.tar.xz
# tar -xvf Python-2.7.8.tar

Vamos al directorio del python y realizamos la configuración y la compilación:

# cd Python-2.7.8
# ./configure –prefix=/usr/local
# make

Ahora podemos instalarlo sin sobrescribir el del sistema con la siguiente orden:

# make altinstall

Instalación de las herramientas de python pip y virtualenv

En primer lugar necesitamos instalar las setup_tools:

# wget –no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz
# tar -xvf setuptools-1.4.2.tar.gz
# cd setuptools-1.4.2
# python2.7 setup.py install

Ahora ya podemos instalar pip:

#curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python2.7

E instalamos virtualenv desde pip:

#pip install virtualenv

Uso del entorno virtual desde una cuenta de usuario.

$ virtualenv django
New python executable in django/bin/python2.7
Also creating executable in django/bin/python
Installing setuptools, pip…done.

$ source ./django/bin/activate

Guía SEO para principiantes

Estaba dándome una vuelta por la herramientas para webmasters de google (https://www.google.com/webmasters) y me he encontrado con la Guía para principiantes sobre optimización para motores de búsqueda de Google

Me ha parecido muy interesante ya que es algo muy básico que todo informático debería conocer.

Yo colaboré ya hace años en un artículo en JoseanE.com que escribí junto con Josefina denominado al ABC del posicionamiento web en el que ya se resaltaban estos conceptos.

La guía de google es muy completa y de obligada lectura si tienes una página web o un blog.

Instalación de SNMP en Centos 6

Centos 6 en su configuración mínima ya incluye el servidor net-snmp, cosa que podemos verificar con la orden:

[root@nexus3 ~]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: sunsite.rediris.es
* epel: mirror.uv.es
* extras: sunsite.rediris.es
* updates: sunsite.rediris.es
Installed Packages
net-snmp.x86_64           1:5.5-44.el6_4.4            @updates

Sin embargo no están instaladas las utilidades, las cuales podemos instalar con:

[root@nexus3 ~]# yum install net-snmp-utils

Para configurar el servidor snmp debemos editar el archivo /etc/snmp/snmpd.conf

El archivo está comentado, podemos por ejemplo definir la información de contacto, en las líneas:

syslocation UPV DISCA despacho 3S7
syscontact [email protected]

Para poner el servicio en funcionamiento escribimos:

[root@nexus3 ~]# service snmpd start
Iniciando snmpd: [ OK ]

Podemos hacer que arranque automáticamente con:

[root@nexus3 ~]# chkconfig snmpd on

También podemos usar el webmin para configurar el servicio en las sección de Sistema > «Arranque y Parada»

Podemos probarlo con las siguientes líneas:

[root@nexus3 ~]# snmpget -v 1 -c public localhost sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux nexus3.disca.upv.es 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64
[root@nexus3 ~]# snmpget -v 1 -c public localhost sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: [email protected]
[root@nexus3 ~]# snmpget -v 1 -c public localhost sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: UPV DISCA despacho 3S7

También podemos acceder a toda la información con la orden:
[root@nexus3 ~]# snmpwalk -v 1 -c public localhost
SNMPv2-MIB::sysDescr.0 = STRING: Linux nexus3.disca.upv.es 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (165663) 0:27:36.63
SNMPv2-MIB::sysContact.0 = STRING: [email protected]
SNMPv2-MIB::sysName.0 = STRING: nexus3.disca.upv.es
SNMPv2-MIB::sysLocation.0 = STRING: UPV DISCA despacho 3S7
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.3 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.6 = STRING: The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.7 = STRING: The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.8 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (2) 0:00:00.02
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (25949783) 3 days, 0:04:57.83
End of MIB

Cambiar el alias de root

Los que todavía no lo hayáis hecho, os pido que configuréis el alias de root en vuestra máquina virtual con vuestro email de forma que todos los correos que vayan dirigidos a root os lleguen a vosotros (y no a mí).

Para esto tenéis que ir al virtualmin y seleccionar webmin, Servidores, Configuración de Postfix

Y seleccionar Aliases de Correo

Buscar la entrada root y editarla para que ponga vuestro correo.

Cambiar el puerto de acceso para phpmyadmin

El objetivo es poder acceder a phpmyadmin con el formato:

https://dominio:10080/phpmayadmin

Pasos necesarios:

1. Activar ssl en nuestra web, lo hacemos en la sección de Editar Servidor Virtual de virtualmin

Marcando Sitio web SSL habilitado

2. Vamos a webmin, servidores, servidor web Apache y creamos un nuevo servidor virtual con las mismas características que el que tenemos en el puerto 443, pero cambiando el puerto al 10080 (hay varias opciones para hacer esto)

Verificaremos que podemos acceder con 10080.

3. Mediante un archivo .htaccess en el directorio phpmyadmin (usando mod_rewrite) hay que conseguir que cualquier acceso a este directorio con un puerto distinto al 10080 salte a la url con el puerto 10080.

4. Para que esto sea de utilidad es necesario haber configurado el cortafuegos para que a nuestra IP nos de acceso a todos los puertos y el puerto 10080 no esté abierto, de forma que sólo se pueda acceder a phpmyadmin desde nuestra IP.

Instalación de phpmyadmin con virtualmin

La aplicación phpmayadmin, se puede instalar directamente desde el panel de control virtualmin de forma similar a como se instala roundcube, pero antes de instalarla es necesario instalar el repositorio epel, ya que phpmyadmin utiliza el paquete mcrypt que no tenemos instalado en centos 6.4 y además no se incluye en los repositorios estándar.

Para instalar el repositorio epel, lo vamos a hacer desde la consola o desde una terminal ssh como root, y seguiremos las siguientes instrucciones (en este artículo $ representa el prompt y no se escribe):

Instalación repositorio epel (referencia: http://ithelpblog.com/os/linux/redhat/centos-redhat/how-to-install-epel-repository-on-centos-6-4-or-redhat-6-4-rhel/)

$ wget http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6

$ rpm –import RPM-GPG-KEY-EPEL-6

$ wget http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

$ rpm -ivh epel-release-6-8.noarch.rpm

Podemos verificar que el paquete mcrypt está disponible con la orden

$ yum list mcrypt
…
Available Packages
mcrypt.x86_6      4 2.6.8-10.el6      epel

Ahora ya podemos instalar el phpmyadmin accediendo a la sección «Instala scripts» de vitrualmin