Viejoven en Laredo, Cantabria
Viejoven en Laredo, Cantabria

Para un usuario de Internet normal y corriente, tener su propio servidor en el que poder instalar todo lo que a uno le plazca, es algo que ni le va ni le viene. Pero para cualquier persona que intente profundizar en «las tripas» de la red de redes, llegará un momento en que tenga que plantearse hacer algún tipo de comunicación entre dos máquinas que controle y que pueda personalizar a su gusto.

Hasta el momento, tener un servidor en Internet encendido, disponible y conectado las 24 horas del día, estaba reservado a las empresas. Mantener un equipo así requería un centro de procesado de datos, alimentación eléctrica redundante, acceso a Internet de calidad, copias de seguridad, aire acondicionado, control de accesos, técnicos especializados de mantenimiento en manos remotas… Un considerable esfuerzo económico que estaba justificado para aquellos casos en los que el negocio dependía de alguna manera de tener en línea permanentemente algún servicio en Internet.

La alternativa barata a tener nuestros equipos en un CPD (centro de procesado de datos) era tenerlos en casa, con el consiguiente gasto en consumo eléctrico, espacio ocupado, pérdida de conectividad por problemas con nuestra conexión a Internet, mantenimiento del hardware… Bastaba (y sigue siendo suficiente) con un PC conectado a nuestro módem ADSL o cablemódem  HFC, redirigir los puertos de nuestro equipo de acceso hacia nuestro servidor y listo. Durante un tiempo tuve este escenario en casa, con las consiguientes molestias del ruido del ventilador del PC dando la matraca.

Llega la nube, pero no nos mojamos

Con la llegada de la virtualización de servidores, se consiguió optimizar el uso de los recursos de un servidor, ejecutando sobre un mismo hardware múltiples instancias de sistemas operativos que compiten por los recursos hardware del anfitrión simultáneamente.

Es entonces cuando surge el concepto de «nube». Las empresas se dan cuenta de que pueden tener ahorros y mejoras en la gestión de sus servidores si los migran a una plataforma virtual,  que podrá estar funcionando en algún sitio de Internet. Si os fijáis, casi siempre que se representa Internet en un diagrama, se pone una nube y se escribe dentro «Internet». Pues digo yo que de ahí sale el concepto nube.

Si la empresa tiene muchos servidores, puede plantearse tener su propia infraestructura de virtualización (nube privada). Si por el contrario gestiona un número bajo de máquinas, puede optar por la virtualización en una nube pública.

Los proveedores de servicios de Internet, Internet Service Providers (ISPs), han evolucionado hacia este tipo de soluciones virtualizadas. Sus centros de datos ahora contienen granjas de servidores de virtualización que están ejecutando instancias de sistemas operativos de múltiples clientes de cualquier parte del mundo.

Pero pronto grandes empresas, que aparentemente poco tienen que ver con este tipo de servicios, se han hecho con el liderazgo en el mercado. Un ejemplo claro es Amazon. Su necesidad de tener una potente base de servidores para atender las peticiones de su tienda online, les llevó a desarrollar una infraestructura y tecnología propias que han sabido convertir en uno de los mejores servicios de virtualización actuales.

En este artículo os quiero contar cómo se puede tener una web con WordPress en nuestro propio servidor y además con el tráfico web cifrado.

El primer paso es hacernos con un servidor virtual.

Amazon Lightsail

El pasado octubre de 2016, Amazon lanzó Lightsail, un servicio destinado a cubrir un segmento de mercado que demandaba la posibilidad de tener máquinas virtuales a muy bajo precio. Por 5€ al mes, podemos tener nuestra propia máquina virtual con Linux.

Naturalmente es una máquina con capacidades limitadas de disco, memoria y CPU. También el tráfico de datos está limitado a 1 Tera byte mensual, pero es suficiente como para que podamos tener nuestra propia web o experimentar con cualquier software.

Crear una máquina virtual en LightSail es tan sencillo como darse de alta (tened vuestra tarjeta de crédito a mano), elegir la opción «Os Only» y seleccionar entre «Amazon Linux» o «Ubuntu». Yo he elegido Ubuntu, por eso de que Debian siempre ha sido mi sistema operativo favorito y Ubuntu es su primo.

Creación de una máquina virtual Linux en Amazon LigthSail
Creación de una máquina virtual Linux en Amazon LigthSail

La máquina virtual se crea en pocos segundos y nos aparecerá información parecida a esta:

Máquina virtual Ubuntu en Lightsail
Máquina virtual Ubuntu en Lightsail

Tenemos que apuntar la dirección IP pública que nos han asignado (34.193.1.64) y verificar que las reglas del cortafuegos que incluye la plataforma están abiertas para:

  • 80 TCP
  • 443 TCP
Reglas del firewall en LightSail
Reglas del firewall en LightSail

La gestión remota del servidor se realiza a través de SSH y Putty. El puerto 81 lo abrí para cacharrear con WS y Swagger, así que no es necesario tenerlo abierto.

Instalación de WordPress

Descargaremos la versión en español de es.wordpress.org y seguimos los pasos de su famosa famosa Instalación en 5 minutos. Recuerda que como paso previo necesitas un usuario con permisos de lectura y escritura en tu base de datos Mysql.

Mysql, también

Así he instalado yo Mysql. Tras arrancar Putty y entrar en el servidor virtual con mi nombre de usuario y contraseña:

aorviz@maquina:~$ sudo apt-get install mysql-server

Durante el proceso nos pedirá la contraseña para el usuario «root». Una vez introducida la contraseña, nos pedirá confirmación de la misma.

Solicitud password de root para la bbdd
Solicitud password de root para la bbdd

Finalizada la instalación creamos la base de datos para nuestro WordPress. Entramos a la administración de la base de datos con el usuario «root» y la contraseña que hemos escrito durante la instalación. Entiéndase bien: no es el usuario root de nuestro Linux sino otro «root» de la base de datos. No tienen nada que ver pero se llaman igual y ambos son los «superusuarios». Qué lío, ¿eh?

aorviz@maquina:~$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Creamos la base de datos «wordpress». Puede llamarse de cualquier manera, yo he elegido «wordpress» por comodidad.

mysql> CREATE DATABASE wordpress;
Query OK, 1 row affected (0.00 sec)

mysql>

Indicamos al servidor Mysql que tendremos un usuario con todos los permisos de lectura y escritura en las tablas que contenga la base de datos «wordpress». He elegido llamar al usuario «wordpressuser» porque parece bastante fácil de recordar si no lo apuntas. Podéis poner la contraseña que queráis. He escrito «wordpresspassword» a modo de ejemplo.

mysql> GRANT ALL ON wordpress.* TO 'wordpressuser'@'localhost' IDENTIFIED BY 'wordpresspassword';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql>
mysql> quit
Bye
aorviz@maquina:~$

El siguiente paso es configurar el servidor web Apache. Lo que tendremos que hacer es crear «VirtualHost», es decir, hay que decirle al Apache que tiene que mostrar información diferente en función del dominio que se esté visitando.

One momento. Vale, ya la estamos liando. ¿Dominio? ¿No son ya muchas cosas (un servidor virtual, servidor web Apache, un dominio, una base de datos…)? Bueno, evidentemente tenéis soluciones de Hosting compartido muy económicas y que funcionan realmente bien en las que ya os lo dan todo prácticamente hecho. Pero como se trata de aprender lo mejor es meterse en las tripas del asunto: servidor propio y dominio propio.

Hay que tocar el DNS

Para estas pruebas usaré mi dominio orviz.net, pero con cuidado porque no quiero que mi blog deje de funcionar. Crearé una entrada en el interfaz de gestión del DNS que me ofrece mi empresa de Hosting Compartido (en mi caso Telecable) para no interferir con lo que hay funcionando.

¿Qué necesito? Pues elegir un nombre para mi sitio donde desplegaré WordPress y obtener la IP pública de mi servidor virtual que se está ejecutando en LightSail.

Nombre: aws.orviz.net (Por eso de que es una máquina de Amazon Web Services)

IP34.193.1.64.

Desde el interfaz de gestión DNS que me ofrece Telecable añado la siguiente entrada:

Añadimos un registro A al DNS
Añadimos un registro A al DNS

Verificamos que el registro que hemos añadido se está propagando correctamente por Internet:

aorviz@maquina:~$ host aws.orviz.net
aws.orviz.net has address 34.193.1.64
aorviz@maquina:~$

Le metemos mano al Apache

Volvemos con el tema del VirtualHost en Apache. En este artículo de The Geek Stuff se explica muy bien qué configuraciones admite el servidor web Apache. Puesto que nosotros solo tenemos una IP pública en el servidor (y no queremos pagar por más por IPs públicas adicionales porque no es necesario), configuraremos un VirtualHost basado en nombre. Es decir, Apache podrá mostrar contenidos diferentes si accedemos a «aws.orviz.net» o por ejemplo «blog.orviz.net» si lo configurásemos sobre el mismo servidor.

La filosofía de configuración en Apache se basa en tener un directorio con las configuraciones disponibles y otro directorio con las configuraciones habilitadas. Lo que he hecho ha sido copiar la configuración por defecto (000-default.conf) que se crea durante la instalación del apache y que esá en el directorio de «sitios disponibles» y ajustarla a mis necesidades.

aorviz@maquina:/etc/apache2/sites-available$ ls -l
total 16
-rw-r--r-- 1 root root 1327 May 9 16:07 000-default.conf
-rw-r--r-- 1 root root 1347 May 9 16:08 001-aws.orviz.net.conf
-rw-r--r-- 1 root root 6338 Apr 5 2016 default-ssl.conf
aorviz@maquina:/etc/apache2/sites-available$

El archivo 001-aws.orviz.net.conf contiene:

aorviz@maquina:/etc/apache2/sites-available$ cat 001-aws.orviz.net.conf
<VirtualHost *:80>
 # The ServerName directive sets the request scheme, hostname and port that
 # the server uses to identify itself. This is used when creating
 # redirection URLs. In the context of virtual hosts, the ServerName
 # specifies what hostname must appear in the request's Host: header to
 # match this virtual host. For the default virtual host (this file) this
 # value is not decisive as it is used as a last resort host regardless.
 # However, you must set it for any further virtual host explicitly.
 ServerName aws.orviz.net

ServerAdmin webmaster@localhost
 DocumentRoot /var/www/html/wordpress

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
 # error, crit, alert, emerg.
 # It is also possible to configure the loglevel for particular
 # modules, e.g.
 #LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/aws-error.log
 CustomLog ${APACHE_LOG_DIR}/aws-access.log combined

# For most configuration files from conf-available/, which are
 # enabled or disabled at a global level, it is possible to
 # include a line for only one particular virtual host. For example the
 # following line enables the CGI configuration for this host only
 # after it has been globally disabled with "a2disconf".
 #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
aorviz@maquina:/etc/apache2/sites-available$

Solo he hecho dos ajustes básicos:  indicar cuál es el directorio donde están los contenidos de WordPress mediante la variable DocumentRoot y ajustar ServerName a aws.orviz.net.

El siguiente paso es crear el directorio que hemos registrado en DocumentRoot:

aorviz@maquina:~$ cd /var/www/html
aorviz@maquina:/var/www/html$ sudo mkdir wordpress
aorviz@maquina:/var/www/html$

Creado el directorio habilitamos la configuración mediante el comando:

aorviz@maquina:/var/www/html$ sudo a2ensite 001-aws.orviz.net.conf
Enabling site 001-aws.orviz.net.
To activate the new configuration, you need to run:
 service apache2 reload
aorviz@maquina:/var/www/html$ sudo service apache2 reload
aorviz@maquina:/var/www/html$

En este momento si accedemos a nuestro VirtualHost, en mi caso «aws.orviz.net» nos encontraremos con el directorio vacío:

Apache funcionando pero vacío
Apache funcionando pero directorio vacío

La casa por el tejado

Sí, os lo ponía todo de color rosa: descargar WordPress e instalar en cinco minutos, pero nos hemos tenido que currar alguna que otra cosilla entre medio. Ahora sí, vamos al directorio donde tendremos nuestro WordPress, descargamos desde https://es.wordpress.org/ la versión en «tar.gz» y la descomprimimos:

aorviz@maquina:/var/www/html/wordpress$ sudo wget https://es.wordpress.org/wordpress-4.7.5-es_ES.tar.gz
--2017-06-06 12:37:19-- https://es.wordpress.org/wordpress-4.7.5-es_ES.tar.gz
Resolving es.wordpress.org (es.wordpress.org)... 66.155.40.249, 66.155.40.250
Connecting to es.wordpress.org (es.wordpress.org)|66.155.40.249|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8501862 (8.1M) [application/octet-stream]
Saving to: âwordpress-4.7.5-es_ES.tar.gzâ

wordpress-4.7.5-es_ES.tar.gz 100%[====================================================>] 8.11M 2.11MB/s in 4.2s

2017-06-06 12:37:24 (1.92 MB/s) - âwordpress-4.7.5-es_ES.tar.gzâ saved [8501862/8501862]
aorviz@maquina:/var/www/html/wordpress$
aorviz@maquina:/var/www/html/wordpress$ sudo tar xf wordpress-4.7.5-es_ES.tar.gz
aorviz@maquina:/var/www/html/wordpress$

Aquí tenemos un poco de lío porque al descomprimir el paquete comprimido que hemos descargado, nos ha creado un subdirectorio «wordpress» dentro de «wordpress». Arrrg!

Toca borrar /var/ww/html/wordpress y descargar desde /var/www/html. No os doy las instrucciones para que os familiaricéis con los comandos «mv» y «rm».

Arrancamos el instalador de WordPress

Por fin llega el momento que estábamos esperando. Apuntamos con nuestro navegador favorito a «aws.orviz.net» (este es mi ejemplo, poned el vuestro) y nos aparece la pantalla de bienvenida con los requerimientos y siguientes pasos a realizar:

Inicio de la instalación de WordPress
Inicio de la instalación de WordPress

En la siguiente pantalla nos pedirá los datos para conectarnos a nuestra base de datos. ¿Te has acordado de apuntar el nombre de la base de datos, el usuario y la contraseña? Pues toca recuperarlos y escribirlos ahora:

Toca añadir la información para conectarse a la bbdd
Toca añadir la información para conectarse a la bbdd

Ups, ¿qué es este mensaje tan feo?

Mensaje feote
Mensaje feote

Vaya, parece que el instalador de WordPress no ha podido escribir el archivo de configuración. Eso es debido a que el directorio en el que está no tiene los permisos necesarios. Hago lo siguiente: cambio el propietario del directorio al usuario con el que se ejecuta el Apache y creo a mano el archivo «wp-config.php» como  me está indicando. Con esto consigo tener el archivo «wp-config.php» en modo lectura, pero propietario de root, para que no lo toque por error.

aorviz@maquina:/var/www/html$ sudo chown -R www-data: wordpress/
aorviz@maquina:/var/www/html$ cd wordpress/
aorviz@maquina:/var/www/html/wordpress$ sudo vi wp-config.php

Y hago un «copy+paste» de lo que me indica el instalador.

El siguiente paso es introducir los ajustes iniciales del sitio.

Ajustes iniciales del sitio
Ajustes iniciales del sitio

¡Tachán! Ya tenemos nuestro WordPress funcionando. Sí que han sido 5 minutos, pero los pasos previos han sido un poco más dolorosos, ¿verdad?

¡Tachán!
¡Tachán!

Let’s Encrypt

Bien, ya tenemos nuestro servidor funcionando de forma plenamente operativa. Ahora vamos a añadirle una capa de seguridad para que toda la información que se transfiera desde nuestro flamante WordPress recién instalado hacia el navegador de los miles de visitantes que esperan impacientes nuestros contenidos, vaya cifrado. Pero ojo, queremos también que sea un cifrado robusto y que los navegadores no alarmen al usuario con avisos de seguridad ininteligibles y amedrantadores.

Para eso contamos con la iniciativa Let’s Encrypt, que nos facilita un mecanismo gratuito para generar un certificado firmado que se instalará en nuestro servidor. De esta manera, tendremos una comunicación segura y un certificado de seguridad instalado en nuestro servidor web, firmado por una autoridad certificadora que transmitirá confianza a nuestros lectores. Podríamos generar nuestro propio certificado y «autofirmarlo», pero tendríamos avisos de seguridad en los navegadores. Let’s Encrypt es:

  • Gratuito.
  • Automático.
  • Seguro.
  • Transparente.
  • Abierto.
  • Cooperativo.

Pues como  todo son ventajas, ¿qué menos que probarlo?

Lo primero que tenemos que hacer es leernos esto: https://letsencrypt.org/getting-started/ ¿Creéis que en Internet son todo vídeotutoriales? ¡Leed un poco! Farda mucho más decir «lo he configurado leyendo un artículo» que «lo he puesto en marcha siguiendo un videotutorial».

Sigamos. Lo que nos indican inicialmente es que tenemos varias maneras de integrarnos con la infraestructura de generación y renovación de certificados. Como tenemos acceso «shell» a nuestro servidor, nos vamos a https://certbot.eff.org/ que es donde nos recomiendan empezar para instalar el software necesario si tenemos «shell».

CertBot

En la web principal nos guían paso a paso. Nos solicitan el servidor web que tenemos (Apache) y la versión de nuestro sistema operativo para mostrarnos las instrucciones específicas. Para obgtener la versión de Ubuntu que tenemos corriendo en nuestro servidor virtual:

aorviz@maquina:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial
aorviz@maquina:~$
CertBot
CertBot

Tras seleccionar el servidor y el sistema la web nos lleva a las instrucciones concretas para su instalación:

Instrucciones de instalación CertBot para Apache + Ubuntu 16.04.2
Instrucciones de instalación CertBot para Apache + Ubuntu 16.04.2

Tras instalar el software requerido, el último paso es dejar que CertBot se encargue de todo. Bueno, tenemos que ir respondiendo a algunas preguntas. Las he marcado en negrita y en rojo.

aorviz@maquina:~$ sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):micorreo@gmail.com

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: a

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: y

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: aws.orviz.net
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):1
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for aws.orviz.net
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/001-aws.orviz.net-le-ssl.conf
Deploying Certificate for aws.orviz.net to VirtualHost /etc/apache2/sites-available/001-aws.orviz.net-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/001-aws.orviz.net-le-ssl.conf

Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Enabled Apache rewrite module
Redirecting vhost in /etc/apache2/sites-available/001-aws.orviz.net.conf to ssl vhost in /etc/apache2/sites-available/001-aws.orviz.net-le-ssl.conf

-------------------------------------------------------------------------------
Congratulations! You have successfully enabled https://aws.orviz.net

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=aws.orviz.net
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/aws.orviz.net/fullchain.pem. Your cert will
 expire on 2017-09-04. To obtain a new or tweaked version of this
 certificate in the future, simply run certbot again with the
 "certonly" option. To non-interactively renew *all* of your
 certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
 configuration directory at /etc/letsencrypt. You should make a
 secure backup of this folder now. This configuration directory will
 also contain certificates and private keys obtained by Certbot so
 making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
 Donating to EFF: https://eff.org/donate-le

aorviz@maquina:~$

Funcionando feliz como una perdiz. Let’s Encrypt Rules!!!


Also published on Medium.

URL corta del artículo: http://wp.me/p575FY-h6
Avatar

Sobre el autor

Ciudadano

También te puede gustar:

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.