Diferència entre revisions de la pàgina «Storagesis-Manual técnico»

De Wiket
Salta a la navegació Salta a la cerca
Línia 598: Línia 598:
  
 
====Esquema====
 
====Esquema====
−
[[File:esquema5.png|frame|none|]]
+
[[File:esquema5.png|frame|none|Esquema de nuestra infraestructura]]
  
 
En el esquema mostrado en la imagen utilizamos el protocolo IPV4 en el cual el servidor Raspberry 1 tiene la IP 192.168.1.12/24  y el servidor Raspberry 2 la 192.168.1.14/24.
 
En el esquema mostrado en la imagen utilizamos el protocolo IPV4 en el cual el servidor Raspberry 1 tiene la IP 192.168.1.12/24  y el servidor Raspberry 2 la 192.168.1.14/24.

Revisió del 17:55, 24 maig 2018

Instalaciones

En esta sección se explicará que servicios son necesarios para llevar acabo nuestro proyecto

Raspbian

Raspbian es la versión de Debian adaptada para la Raspberry.

Requisitos previos:

  1. Tarjeta SD (mínimo 8GB)
  2. Win32DiskImage
  3. Raspbian Strech Lite

Instalación:
Primero de todo, debe descargar la imagen ISO de Raspbian y Win32DiskImage que encontramos en el enlace anterior. Una vez descargadas, procede a instalar Win32DiskImage. Cuando ya este instalado, se abrirá la siguiente interfaz:

Interfaz Win32DiskImage

Lo único que debe hacer es conectar la tarjeta SD al equipo, seleccionar la imagen ISO descargada anteriormente y pulsar encima de Write.

Interfaz Win32DiskImage con Raspbian.iso

Al acabar este proceso, deberá conectar la tarjeta de memoria SD a la Raspberry. Las credenciales para entrar dentro del sistema son las siguientes: 

Usuario por defecto: pi
Contraseña por defecto: raspbian

Habilitando SSH

En la Raspberry se puede trabajar de dos formas, o bien conectados por HDMI a una pantalla y un teclado o bien remotamente por SSH. En el siguiente caso se trabajará remotamente, desde las 3 Raspberrys, para habilitarlo deberemos introducir los siguientes comandos: 

$ sudo systemctl enable ssh
$ sudo service ssh start

Por seguridad se recomienda cambiar la contraseña por defecto y crear un usuario nuevo con una contraseña segura.

Para publicar el puerto 22 y poder acceder remotamente al servidor, ver apartado 4

Servidor LAMP

Primero actualizar repositorios y paquetes: 

$ sudo apt update && sudo apt upgrade -y

Instalación del sistema de gestión de base de datos MariaDB: 

$ sudo apt install apache2 mariadb-server php7.0 phpmyadmin

Configurando usuario root MariaDB

Por defecto el usuario root de MariaDB viene des-habilitado para habilitarlo y darle una contraseña haremos lo siguiente: 

$ sudp mysql_secure_installation

Y en el asistente que nos aparece seguir las instrucciones. Aquí mi ejemplo de como lo he configurado 

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] Y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Y
 ... Success!

HAproxy

Este software se utilizará para el balanceo de carga y alta disponibilidad, se deberá de instalar en el Servidor3 

$ sudo apt install haproxy

Owncloud

Owncloud es un servicio de alojamiento en la nube.

Descargamos la ultima versión actual dentro de los servidores 

$ wget https://download.owncloud.org/community/owncloud-10.0.8.zip

Cuando este descargado se debe descomprimir con el siguiente comando 

$ unzip owncloud-10.0.8.zip

Se procederá a mover el directorio descomprimido a donde se quiere alojar la carpeta, en mi caso será la ruta /var/www/html/ 

$ sudo mv owncloud/ /var/www/html/

Y se cambiará el propietario de la siguiente forma 

$ sudo chown -R www-data:www-data /var/www/html/owncloud

Instalamos todas las dependencias de php para el correcto funcionamiento de owncloud 

$ sudo apt install libapache2-mod-php-apcu php-redis redis-server php7.0-ldap php7.0 php-imagick php7.0-common php7.0-curl php7.0-gd php7.0-imap php7.0-intl php7.0-json php7.0-ldap php7.0-mbstring php7.0-mcrypt php7.0-mysql php7.0-pgsql php-smbclient php-ssh2 php7.0-sqlite3 php7.0-xml php7.0-zip

Procedemos a crear un usuario con privilegios adecuados para que pueda ser administrado por owncloud y la base de datos para owncloud 

$ sudo mysql -u root -p
MariaDB [(none)]> CREATE DATABASE owncloud;
MariaDB [(none)]> CREATE USER 'dbadmin'@'localhost' IDENTIFIED BY '@tu_contraseña';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'localhost' WITH GRANT OPTION;
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> exit

Una vez hecho estos pasos para acabar la instalación, deberemos ir al apartado 2 Configuración de servicios - Apache para realizar una correcta instalación.

Una vez realizada las configuraciones del apartado 2, se procede a instalar owncloud desde el navegador, deberemos poner nuestra dirección IP y rellenar los datos, en mi caso, será de la siguiente forma:

FALTA IMAGEN

Servidor de correo

Configurar un servidor de correo es una tarea compleja debido a que se compone de varios procesos: MTA (Mail Transfer Agent), MDA (Mail Delivery Agent), anti-spam, antivirus, etc.

El sistema contenedores Docker nos facilita este proceso, ya que Docker permite crear máquinas con la configuración deseada y subirlas para que la comunidad las aproveche. Nosotros utilizaremos una máquina dockeritzada con un servidor de correo.

Para hacerlo utilizaremos una máquina virtual de Amazon AWS EC2. La elección no es trivial, ya que esta máquina amazon nos proporciona una IP fija, la cual es necesaria debido a que las IP's dinámicas estan en una lista negra y los grandes servidores como gmail o hotmail no nos permiten enviarles correos.


Lo primero que tendremos que hacer es abrir los puertos de nuesta máquina amazon para poder recibir y enviar correos. Los puertos que debemos abrir son:

  • 25
  • 465
  • 993
  • 587

Una vez abiertos los puertos podremos hacer una comprobación instalando el paquete nmap en nuestra máquina amazon: 

$ sudo apt install nmap

Seguidamente ejecutaremos este comando: 

$ sudo nmap localhost

La salida debe ser similar a esta: 

ubuntu@ip-172-31-17-185:~$ nmap localhost

Starting Nmap 7.01 ( https://nmap.org ) at 2018-05-10 17:09 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
143/tcp open  imap
587/tcp open  submission
993/tcp open  imaps

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Como podemos comprobar ya tenemos los puertos necesarios habilitados.

A continuación deberemos de crear registros en nuestro dominio, ya que el correo electrónico utiliza registros MX.

Nosotros utilizamos Cloudflare para gestionar los nombres DNS. Simplemente deberemos añadir un registro MX que apunte a un registro A con la IP pública de la máquina virtual de Amazon AWS EC2. Aquí una captura del resultado:

Como vemos hay dos registros A. Esto se debe a que tenemos un registro apuntando a la IP pública de casa con el servidor web y otro apuntando a la IP pública de Amazon para el servidor de correo.

Una vez tengamos los registros correctamente, deberemos ir a la terminal de nuestra máquina Amazon e instalar el software necesario: 

$ sudo apt install docker-compose docker

A continuación, crearemos una carpeta para almacenar los archivos de configuración: 

$ sudo mkdir ~/Mail-Server

Seguidamente nos dirigimos a la carpeta creada: 

$ sudo cd ~/Mail-Server

Ahora nos bajaremos la máquina dockeritzada con el servidor de correo: 

 $ sudo docker pull tvial/docker-mailserver:latest

Después nos bajaremos estos tres archivos de configuración: 

sudo curl -o setup.sh https://raw.githubusercontent.com/tomav/docker-mailserver/master/setup.sh;sudo chmod a+x ./setup.sh
sudo curl -o docker-compose.yml https://raw.githubusercontent.com/tomav/docker-mailserver/master/docker-compose.yml.dist
sudo curl -o .env https://raw.githubusercontent.com/tomav/docker-mailserver/master/.env.dist

Deberemos editar el archivo .env y deshabilitar el módulo FAIL2BAN: 

 - ENABLE_FAIL2BAN=0

Ahora crearemos las cuentas de usuario de correo: 

$ sudo ./setup.sh email add [email protected] contraseña

DDoS Deflate

Con este script evitaremos ataques DDOS. Para instalarlo deberemos ejecutar los siguientes comandos 

wget https://github.com/jgmdev/ddos-deflate/archive/master.zip
unzip master.zip
cd ddos-deflate-master
./install.sh

Para desinstalar este scrip ejecutaremos el siguiente comando 

cd ddos-deflate-master
./uninstall.sh

Para añadir IP's a la lista blanca y que no sean baneadas deberemos editar el siguiente archivo y añadiríamos las direcciones IP que deseamos 

$ sudo nano /etc/ddos/ignore.ip.list

Configuración de Router

En este apartado se muestra como se abren los puertos en un Router ZTE F680 para publicar nuestros servicios en de las Raspberrys. En este ejemplo se muestra como publicar SSH, pero tambien funcionará para HTTP y HTTPS.

Primero de todo debemos entrar en nuestra interfaz de configuración del router, por defecto es http://192.168.1.1 e introducir nuestras credenciales, una vez dentro, para publicar los puertos iremos a la sección Application -> Application List

Application router.png

Donde aparecerá una tabla como la siguiente, donde deberemos apretar encima del enlace Click here to add an application.

Add app.png

Dónde solo nos hará falta rellenar los datos con los puertos que queremos usar mi ejemplo para el servicio ssh quedará de la siguiente forma

Ssh router.png

Pulsamos sobre Add y se guardaría la configuración, ahora deberemos hacer que el servidor al que nos queramos conectarnos remotamente tenga publico el servicio, para ello iremos a Port forwarding (Application List)

Application list.png

Ahora en la nueva sección tan solo debemos introducir en LAN Host IP Address la dirección IP del servidor que queramos conectarnos remotamente, en mi caso será al servidor HAproxy

Ssh publicado.png

Configuración de servicios

En este apartado se explicará como configurar cada servicio instalado para el correcto funcionamiento de estos.

Disco duro externo

Servidor

Para compartir el disco duro por red se deberá instalar samba en el servidor donde se enchufará el disco duro a los puertos USB de una de las Raspberry.Este disco duro tendrá que tener el formato ext4 o ntfs. 

$ sudo apt install samba

Creamos una copia de seguridad del archivo smb.conf 

$ sudo cp /etc/samba/smb.conf /ruta/de/destino

Ahora miramos en que particion esta nuestro disco duro con el siguiente comando 

$ sudo fdisk -l

En mi caso estará en /dev/sda1 

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1          63 976768064 976768002 465.8G  c W95 FAT32 (LBA)

Crearemos una carpeta dentro de /mnt y la montaremos 

$ sudo mkdir /media/Owncloud
$ sudo mount /dev/sda1 /media/Owncloud/
$ sudo chowm -R www:data:www-data /media/Owncloud

Creamos una contraseña para el usuario 

sudo smbpasswd -a @usuario_sistema

Procedemos a editar el archivo smb.conf 

$ sudo nano /etc/samba/smb.conf

Y añadimos al final del archivo la siguiente configuración 

[Owncloud]
path=/media/Owncloud
available = yes
valid users = terrange, ander
browsable = yes
public = yes
writable = yes
force user = www-data
force group = www-data
create mode = 0770
directory mode = 0770
force create mode = 0770
force directory mode = 0770

Y reiniciamos el servicio 

$ sudo /etc/init.d/samba restart

Cliente

Para montar la unidad que acabamos de compartir necesitaremos tener instalado el software cifs-utils. 

$ sudo apt install cifs-utils

Creamos una carpeta dentro de /mnt 

$ sudo mkdir /media/Owncloud

Montaremos la unidad compartida para que en el Servidor2, se monte automáticamente al iniciar sistema, para ello creamos el siguiente fichero. 

$ sudo nano /etc/cifs.credentials

Añadiremos el usuario con las credenciales apra poder conectarse al servidor samba 

username=@nombre_usuario_samba
password=@contraseña_usuario_samba

Después añadiremos la siguiente linea dentro del archivo /etc/fstab 

$ sudo nano /etc/fstab
//@dirección_ip/Owncloud /media/Owncloud cifs uid=33,gid=33,file_mode=0770,dir_mode=0770,credentials=/etc/cifs.credentials 0 0

Solo quedaría reiniciar el equipo y estaría todo listo.

Apache2

Se habilitarán los siguientes módulos de apache2 para el correcto funcionamiento 

$ sudo a2enmod rewrite
$ sudo a2enmod headers
$ sudo a2enmod env
$ sudo a2enmod dir
$ sudo a2enmod mime

En caso de que no se tenga des-habilitado el sitio 000-default.conf procedremos a des-habilitarlo con el siguiente comando

$ a2dissite 000-default.conf

Creamos un nuevo archivo .conf, se le podrá llamar de cualquier forma en mi caso será de la siguiente forma 

$ sudo nano /etc/apache2/sites-available/owncloud.conf

Y dentro de este, añadimos la siguiente configuración 

<VirtualHost *:80>
        ServerAdmin tu_correo@dominio
        ServerName tudominio.com
        ServerAlias www.tudominio.com

        DocumentRoot ruta_de_owncloud
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
        # Logfiles
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        <Directory ruta_de_owncloud>
            Options FollowSymLinks
            DirectoryIndex index.php
            Options Indexes FollowSymLinks Includes ExecCGI
            AllowOverride None
            Order deny,allow
            Allow from all
            Require all granted
        </Directory>
</VirtualHost>

Y se habilita esta nueva zona con el siguiente comando 

$ sudo a2enmod owncloud.conf

HAproxy

Creación certificados

En este apartado se explicará como configurar ssl con el programa Certbot.

Primero de todo, se debe descargar el software 

$ sudo apt install certbot

En caso de no tenerlo en los repositorios se agregará de la siguiente forma 

$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt update
$ sudo apt install certbot

Comprobar que el puerto 80 no tiene ningún tipo de servicio ejecutando, en nuestro caso HAproxy, para ello se debe parar el servicio 

$ sudo /etc/init.d/haproxy stop

Se verificará que el puerto 80 no haya nada: 

$ netstat -na | grep ':80.*LISTEN'

Ahora se crea el certificado 

$ sudo certbot certonly --standalone --preferred-challenges http --http-01-port 80 -d example.com -d www.example.com

Si nos sale el siguiente mensaje es que todo ha ido bien. 

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your cert
   will expire on 2017-09-06. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot again. 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

Se procede hacer un ls para comprobar que estén los archivos siguientes archivos 

$ sudo ls /etc/letsencrypt/live/tu_dominio
cert.pem chain.pem fullchain.pem privkey.pem

Se procederá a combinar los archivos fullchain.pem y privkey.pem, se crea un directorio para almacenar el certificado resultante en el directorio siguiente 

$ sudo mkdir -p /etc/haproxy/certs

Y ahora se combina los archivos mencionados anteriormente con el siguiente comando 

$ DOMAIN='example.com' sudo -E bash -c 'cat /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/letsencrypt/live/$DOMAIN/privkey.pem > /etc/haproxy/certs/$DOMAIN.pem'

Ahora cambiamos los permisos a los certificados

$ sudo chmod -R go-rwx /etc/haproxy/certs

Balanceo Apache

Para hacer un balanceo de carga para los dos servidores apache, deberemos añadir las siguientes líneas en el archivo haproxy.cfg, para abrir este archivo teclearemos lo siguiente en nuestra terminal. 

$ sudo nano /etc/haproxy/haproxy.cfg

y añadimos las siguientes lineas al final del archivo 

frontend http
   bind *:80
   reqadd X-Forwarded-Proto:\ http
   default_backend www-backend

frontend https
   bind *:443 ssl crt /ruta/de/los/certificados
   reqadd X-Forwarded-Proto:\ https
   acl letsencrypt-acl path_beg /.well-known/acme-challenge/
   use_backend letsencrypt-backend if letsencrypt-acl
   default_backend www-backend

Explicaré las líneas que considero más importante

  • bind: Le dice a HAproxy por donde recibirá las peticiones web.
  • reqadd X-Forwarded-Proto:\ http o https: Añade un encabezado http o https al final de la solicitud.
  • default_backend www-backend: Especifica que todo el trafico que le llega del frontend será redirigido a la configuración del backend.
backend www-backend
   balance leastconn
   cookie SRVNAME insert
   redirect scheme https if !{ ssl_fc }
   server Apache1 192.168.1.12:80 check cookie Apache1 check
   server Apache2 192.168.1.14:80 check cookie Apache2 check

backend letsencrypt-backend
   server letsencrypt 127.0.0.1:54321
  • balance leastconn : Es el mecanismo para balancear, consiste en elegir el servidor con menos conexiones, se recomienda usar para largas conexiones.
  • cookie SRVNAME insert: Habilita las cookie.
  • redirect scheme https if !{ ssl_fc }: Redirige todo el tráfico HTTP a HTTPS.
  • server Apache1 192.168.1.12:80 check cookie Apache1 check: En esta linea añadimos el primer servidor que ofrecerá el servicio web, debemos especificar la dirección IP como el puerto por el cual esta ejecutando el servicio web.
  • server Apache2 192.168.1.14:80 check cookie Apache2 check: En esta linea añadimos el segundo servidor que ofrecerá el servicio web, debemos especificar la dirección IP como el puerto por el cual esta ejecutando el servicio web.

Peticiones a MariaDB - Maestro

En este apartado se explica como hacer que todas las peticiones se dirigan al servidor maestro. Debemos crear el usuario correspondiente 

$ sudo mysql -u root -p
MariaDB[(none)]USE mysql;
MariaDB [(mysql)]> INSERT INTO user (Host, User) values ('@dir_ip_HAproxy','haproxy_check');
MariaDB [mysql]> FLUSH PRIVILEGES;
MariaDB [mysql]> GRANT ALL PRIVILEGES ON *.* TO 'haproxy_root’@’@dir_ip_HAproxy' IDENTIFIED BY '@tu_contraseña' WITH GRANT OPTION;
MariaDB [mysql]> FLUSH PRIVILEGES;
listen mariadb
   bind 192.168.1.15:3306
   mode tcp
   option mysql-check user haproxy_check
   server Apache1 192.168.1.12:3306 check

Archivo haproxy.cfg

Ahora se procede a modificar el archivo de configuración para hacer de balanceador y disponer de alta disponibilidad, tanto para el servidor MariaDB como para Apache2.

Para ello añadiremos estas opciones al final del archivo, modificando las direcciones IP 

frontend http
   bind *:80
   reqadd X-Forwarded-Proto:\ http
   default_backend www-backend

frontend https
   bind *:443 ssl crt /ruta/de/los/certificados
   reqadd X-Forwarded-Proto:\ https
   acl letsencrypt-acl path_beg /.well-known/acme-challenge/
   use_backend letsencrypt-backend if letsencrypt-acl
   default_backend www-backend

backend www-backend
   balance leastconn
   cookie SRVNAME insert
   redirect scheme https if !{ ssl_fc }
   server Apache1 192.168.1.12:80 check cookie Apache1 check
   server Apache2 192.168.1.14:80 check cookie Apache2 check

backend letsencrypt-backend
   server letsencrypt 127.0.0.1:54321

listen mariadb
   bind 192.168.1.15:3306
   mode tcp
   option mysql-check user haproxy_check
   server Apache1 192.168.1.12:3306 check

Servidor de correo

En este apartado se hablará de como configurar correctamente los archivos de configuración

Seguridad en servidor de correo

Para que los correos de nuestro servidor no sean catalogados como SPAM deberemos añadir sistemas para asegurar el origen de los correos e impedir que cualquiera pueda enviar emails sin importar el remitente. Estos sistemas son:

  • DKIM: Se trata de firmar todos nuestros correos con nuestra clave privada y públicar la pública en nuestro servidor DNS.
  • SPF: Se trata de asociar unas IP's concretas desde las cuales será válido enviar correos de nuestro dominio.
  • DMARC:
DKIM

Primero deberemos de generar las claves DKIM: 

$ sudo ./setup.sh config dkim

A continuación nos dirigimos a la ruta /home/ubuntu/Mail-Server/config/opendkim/keys/tu-dominio/ y copiamos la información del archivo mail.txt. Deberemos copiar lo que está entre paréntesis, sin comillas y sin espaciados.

Una vez copiada la clave pública correctamente deberemos añadir un registro TXT en nuestro servidro DNS y añadir la clave pública en el valor del registro.

SPF

Deberemos crear un archivo llamado postfix-policyd-spf.conf en la ruta /home/ubuntu/Mail-Server/config y añadir estas lineas: 

debugLevel = 1
skip_addresses = 127.0.0.0/8
Domain_Whitelist = mail.storagesis.tk

En este archivo le indicamos las IP's validas y el dominio de nuestro servidor de correo.

A continuación deberemos modificar el archivo docker-compose.yml y añadir esta linea en el apartado de volumes: 

- ./config/postfix-policyd-spf.conf:/etc/postfix-policyd-spf-python/policyd-spf.conf

Una vez añadida esta linea, detenemos el servidor y lo volvemos a encender para que se apliquen los cambios: 

$ sudo docker-compose down
$ sudo docker-compose up -d

Por último deberemos crear un registro TXT en nuestro servidor DNS y añadir esta linea en el campo valor: 

 v=spf1 mx ~all
DMARC

DMCAR al igual que DKIM y SPF es una medida para hacer que el dominio de correo sean validos y no se consideren como dominios de correo fraudulento. Para configurar DMARC, lo único que deberemos hacer es añadir un registro TXT con la siguiente información 

Nombre: _dmarc
Value: v=DMARC1; p=none
Resultado

Aquí vemos el resultado final de los registros creados en nuestro servidor DNS:

Cloudflare2.png

Archivo .env

Primero de todo, se deben modificar las siguientes variables para una correcta configuración 

HOSTNAME=@tu_subdominio
DOMAINNAME=@tu_dominio
TLS_LEVEL=intermediate 
ENABLE_CLAMAV=0 
SSL_TYPE=letsencrypt
ENABLE_SPAMASSASSIN=1

HOSTNAME: Nombre de tu subdominio
DOMAINNAME: Nombre de tu dominio
TLS_LEVEL: Esta opción por defecto viene vacia, pero se debe cambiar a intermediate ya que es realmente importante porque depende de que owncloud se conecte al dominio y pueda enviar los correos adecuadamente, ya que activa las versiones de TLSv1.0, TLSv1.1 y TLSv1.2.
ENABLE_CLAMAV: Esta opción por defecto viene en 0, 1 es para activarla y sirve para activar el antivirus, no lo recomiendo ya que ralentiza mucho la maquina.
SSL_TYPE: Esta opción viene vacía, nosotros pondremos letsencrypt para los certificados, más adelante explicaré como se configura.
ENABLE_SPAMASSASSIN: Cambiamos el valor de 0 a 1.

SSL

Para hacer esto instalamos el certbot como explicamos en la sección 2.2.1 Configuración de certificado. Únicamente deberemos ejecutar el siguiente comando 

$ sudo certbot certonly --standalone --preferred-challenges http --http-01-port 80 -d example.com -d www.example.com

Estando esto listo, deberemos modificar el archivo de configuración docker-compose.yml y añadir las siguientes líneas 

    - ./config/postfix-policyd-spf.conf:/etc/postfix-policyd-spf-python/policyd-spf.conf
    - /etc/letsencrypt:/etc/letsencrypt

Quedando el siguiente resultado 

    volumes:
    - maildata:/var/mail
    - mailstate:/var/mail-state
    - ./config/:/tmp/docker-mailserver/
    - ./config/postfix-policyd-spf.conf:/etc/postfix-policyd-spf-python/policyd-spf.conf    
    - /etc/letsencrypt:/etc/letsencrypt

Lo que se hace con las siguientes lineas es lo siguiente ./config/postfix-policyd-spf.conf:/etc/postfix-policyd-spf-python/policyd-spf.conf: Añade la configuración del SPF dentro del docker para que funcione correctamente. /etc/letsencrypt:/etc/letsencrypt: Monta toda la carpeta con los certificados dentro del docker.

Comprobación

El primer paso para comprobar que nuestro servidor de correo funciona correctamente es usar el siguiente escaneador de dominios de correo. Si todo se ha configurado bien, debería aparecer algo parecido a la siguiente foto

Test SSL encryption

Segundo paso realizar, una comprobación de la puntuación que tiene nuestro servidor de correo, para realizar este test, usaremos el siguiente mail-tester. Enviaremos el correo a la dirección que nos pone, y deberá otorgarnos la puntuación, en mi caso es esta

Test puntuación

Replicación Maestro-Maestro con MariaDB

Objetivo

El objetivo es crear una replicación Maestro - Maestro en el sistema de gestión de base de datos MariaDB. Se implementará en nuestros dos servidores Raspberry que incorporan el SO Raspbian sin escritorio y el servicio web Apache2.

Todo esto con el propósito de agregar velocidad y redundancia a nuestro servicio para que actúen como un clúster. El clúster de base de datos, será especialmente útil debido a que disponemos de alta disponibilidad en cuanto a servidores.

Esquema

Esquema de nuestra infraestructura

En el esquema mostrado en la imagen utilizamos el protocolo IPV4 en el cual el servidor Raspberry 1 tiene la IP 192.168.1.12/24 y el servidor Raspberry 2 la 192.168.1.14/24.

Maestro Servidor Raspberry 1

Tendremos que añadir estas líneas en el archivo my.cnf ubicado en la ruta /etc/mysql/: 

[mysqld]
log-bin
server_id=1
log-basename=master1
bind-address= 0.0.0.0
binlog_do_db= owncloud
binlog_format = row

A continuación guardamos la configuración y reiniciamos el servicio MariaDB: 

$ sudo systemctl restart mariadb

Una vez reiniciado el servicio, nos conectamos a la consola de mariaDB con un usuario con todos los permisos en mi caso el usuario Anderson: 

$ sudo mysql -u Anderson -p

Nos pedirá la contreseña de usuario y ya estaremos dentro. A continuación crearemos el usuario replicator: 

MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replicator'@'192.168.1.14' IDENTIFIED BY 'password';

Sintaxis: 

MariaDB [(none)]> GRANT [permiso] ON [nombre de bases de datos].[nombre de tabla] TO '[usuario]'@'[tipo_de_conexión]' IDENTIFIED BY '[contraseña]';

Explicación de comando ejecutado:

Con este comando le estamos dando permisos de REPLICATION SLAVE y REPLICATION CLIENT al usuario replicator con contraseña password sobre todas las bases de datos y todas las tablas, le indicamos que la conexión solo será permitida desde la IP 192.168.1.14, és decir, desde el servidor Raspberry 2.


REPLICATOR SLAVE:Permite al usuario esclavo conectarse al otro servidor como si fuera su maestro.

REPLICATION CLIENT: Permite el uso de los comandos SHOW MASTER STATUS, SHOW SLAVE STATUS y SHOW BINARY LOGS.

A continuación ejecutamos este comando y nos guardamos la información saliente: 

MariaDB [(none)]> SHOW MASTER STATUS;

Nos saldrá algo parecido a esta imagen:

Master1.png

Maestro Servidor Raspberry 2

Al igual que en el servidor Raspberry 1 tendremos que añadir estas líneas al final del fichero my.cnf: 

[mysqld]
log-bin
server_id=2
log-basename=master2
bind-address= 0.0.0.0
binlog_do_db= owncloud
binlog_format = row

Como vemos el valor de los parámetros server_id y log_basename cambia. El valor de server_id debe ser único en cada servidor y el nombre del archivo log cambia para poder diferenciarlos facilmente.

A continuación guardamos la configuración y reiniciamos el servicio de MariaDB: 

$ sudo systemctl restart mariadb

Una vez reiniciado el servicio, nos conectamos a la consola de mariaDB con un usuario con todos los permisos en mi caso el usuario Anderson: 

$ sudo mysql -u Anderson -p


Nos pedirá la contreseña de usuario y ya estaremos dentro. A continuación crearemos el usuario replicator: 

MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replicator'@'192.168.1.12' IDENTIFIED BY 'password';

Como vemos lo único que varia respecto al servidor Raspberry 1 es la dirección desde la cual se puede conectar: 192.168.1.12.

Seguidamente deberemos ejecutar este comando para parar el servicio esclavo: 

MariaDB [(none)]> STOP SLAVE;

El siguiente paso consiste en en utilizar la información obtenida del servidor Raspberry 1 y aplicarla a nuestro comando: 

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST = '192.168.1.12', MASTER_USER = 'replicator', MASTER_PASSWORD = 'password', MASTER_PORT = 3306, MASTER_LOG_FILE = 'master1-bin.000004', MASTER_LOG_POS = 329, MASTER_CONNECT_RETRY = 10;

Explicación de comando ejecutado:

Con este comando cambiamos el host master por la dirección IP del servidor Raspberry 1. Asignamos el usuario que hará la replicación indicando su contraseña, el puerto, el archivo log, la posición del archivo log y el número máximo de intentos de conexión.

Como podemos observar parte de está información la obtuvimos con el comando "SHOW MASTER" ejecutado en el servidor Raspberry 1 anteriormente.

Iniciaremos el servicio esclavo: 

MariaDB [(none)]>  START SLAVE;

A continuación como hicimos anteriormente con el servidor Raspberry 1, ejecutamos este comando: 

MariaDB [(none)]> SHOW MASTER STATUS;

La salida será algo similar a esto:

Master2.png

Explicación de parámetros del archivo my.cnf

  • log-bin: Instrucción que activa los logs.
  • server_id: Identificador del servidor. Debe ser único y no estar definido en otro grupo de replicación.
  • log-basename: Le damos nombre al log-file.
  • bind-address: Nos permite la conexión remota desde la dirección IP indicada. En este caso desde cualquiera.
  • binlog_do_db: Nombre de la base de datos que queremos replicar. En caso de no añadir este parámetro se replicarán todas las bases de datos.
  • binlog_format (ROW):Almacena en el log-bin las filas modificadas.

Completar proceso en Servidor Raspberry 1

Nos conectamos a la consola de MariaDB: 

$ sudo mysql -u Anderson -p

Detenemos el servicio esclavo: 

MariaDB [(none)]> STOP SLAVE;

Ejecutamos el comando con la información obtenida del servidor Raspberry 2: 

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST = '192.168.1.14', MASTER_USER = 'replicator', MASTER_PASSWORD = 'password', MASTER_PORT = 3306, MASTER_LOG_FILE = 'master2-bin.000005', MASTER_LOG_POS = 329, MASTER_CONNECT_RETRY = 10;

Como podemos observar, lo que cambia es la dirección IP, en este caso la del servidor Raspberry 2 y el nombre del archivo log. Esta vez la posición del archivo log es la misma en ambos servidores, pero no tiene porque ser siempre así.

Por último iniciamos el servicio esclavo: 

MariaDB [(none)]> START SLAVE;

Comprobar replicación Maestro-Maestro

Ahora que ya hemos configurado correctamente ambos servidores, es hora de probarlo. Para ello vamos a crear una tabla en la base de datos owncloud en el servidor Raspberry 1 y comprobar en el servidor Raspberry 2 a ver si se ha creado.

Lo primero que haremos es crear la base de datos owncloud: 

MariaDB [(none)]> CREATE DATABASE owncloud;

Una vez creada añadiremos la tabla prueba: 

MariaDB [(none)]> CREATE TABLE owncloud.prueba(`id` varchar(10));

A continuación nos vamos al servidor Raspberry 2 para comprobar que existe la tabla. Si está todo correcto veremos algo similar a esto:

Prueba1.png

Por último para verificar por completo el maestro-maestro, desde el servidor Raspberry 2 ejecutamos estos dos comandos: 

MariaDB [(none)]> USE DATABASE owncloud; 
MariaDB [(none)]> DROP TABLE prueba;

Deberemos hacer la comprobación de que la tabla no existe en el servidor Raspberry 1. Nos conectamos a la consola de MariDB y ejecutamos este comando: 

MariaDB [(none)]> SHOW TABLES IN owncloud;

El resultado debería ser este:

Prueba2.png

Replicación Maestro-Esclavo con MariaDB

Objetivo

El objetivo es crear una replicación Maestro - Esclavo en el sistema de gestión de base de datos MariaDB. Se implementará en nuestros dos servidores Raspberry que incorporan el SO Raspbian sin escritorio y el servicio web Apache2.

La replicación Maestro - Esclavo con MariaDB nos permite tener copias sincronizadas de nuestra base de datos principal. Esta configuración nos proporciona seguridad, ya que cualquier cambio en el maestro se replicará en el esclavo.

Esquema

Esquema de nuestra infraestructura

En el esquema mostrado en la imagen utilizamos el protocolo IPV4 en el cual el servidor Raspberry 1 tiene la IP 192.168.1.12/24 y el servidor Raspberry 2 la 192.168.1.14/24.

Maestro Servidor Raspberry 1

Tendremos que añadir estas líneas en el archivo my.cnf ubicado en la ruta /etc/mysql/: 

[mysqld]
log-bin
bind-address = 0.0.0.0
server-id = 1
binlog_do_db = owncloud
binlog_format = row

A continuación guardamos la configuración y reiniciamos el servicio MariaDB: 

$ sudo systemctl restart mariadb

Una vez reiniciado el servicio, nos conectamos a la consola de mariaDB con un usuario con todos los permisos en mi caso el usuario Anderson: 

$ sudo mysql -u Anderson -p

Nos pedirá la contreseña de usuario y ya estaremos dentro. A continuación crearemos el usuario replicator: 

MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replicator'@'%' IDENTIFIED BY 'password';

Sintaxis: 

MariaDB [(none)]> GRANT [permiso] ON [nombre de bases de datos].[nombre de tabla] TO '[usuario]'@'[tipo_de_conexión]' IDENTIFIED BY '[contraseña]';

Explicación de comando ejecutado:

Con este comando le estamos dando permisos de REPLICATION SLAVE y REPLICATION CLIENT al usuario replicator con contraseña password sobre todas las bases de datos y todas las tablas, le indicamos que la conexión sea permitida desde cualquier lugar.

REPLICATOR SLAVE:Permite al usuario esclavo conectarse al otro servidor como si fuera su maestro.

REPLICATION CLIENT: Permite el uso de los comandos SHOW MASTER STATUS, SHOW SLAVE STATUS y SHOW BINARY LOGS.

A continuación deberemos seleccionar la base de datos que queremos replicar y bloquear las tablas: 

MariaDB [(none)]> USE owncloud; 
MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;

Seguidamente deberemos hacer un backup de la base de datos seleccionada: 

$ sudo mysqldump -u root -p --opt owncloud > owncloud.sql

Este archivo sql lo pasamos al Servidor Raspberry2 mediante el comando scp: 

 $ sudo scp owncloud.sql [email protected]:/home/ander

Por último desbloquearemos las tablas y veremos el estado del maestro para indicar al esclavo un punto de partida: 

MariaDB [(none)]> UNLOCK TABLES; 
MariaDB [(none)]> SHOW MASTER STATUS;

La salida del comando debería ser similar a esta:

Maestro.png

Esclavo Servidor Raspberry 2

Primero nos conectamos a la consola de mariaDB con un usuario con todos los permisos en mi caso el usuario Anderson: 

$ sudo mysql -u root -p

A continuación creamos la base de datos owncloud: 

MariaDB [(none)]> CREATE DATABASE owncloud;

Seguidamente deberemos restaurar el backup hecho de la base owncloud en el Servidor Raspberry 1: 

$ sudo mysql -u root -p owncloud < owncloud.sql

Una vez restaurada tendremos que modificar el archivo my.cnf ubicado en la ruta /etc/mysql/: 

[mysqld]
log-bin
bind-address = 0.0.0.0
server-id = 2
binlog_do_db = owncloud
binlog_format = row

Para finalizar deberemos activar la replicación, indicando al esclavo cual es su maestro: 

MariaDB [(none)]>  CHANGE MASTER TO MASTER_HOST='192.168.0.12',MASTER_USER='replicator', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000028', MASTER_LOG_POS=328;

Explicación de comando ejecutado:

Con este comando cambiamos el host master por la dirección IP del servidor Raspberry 1. Asignamos el usuario que hará la replicación indicando su contraseña, el nombre del archivo log y su posición.

Como podemos observar parte de está información la obtuvimos con el comando "SHOW MASTER" ejecutado en el servidor Raspberry 1 anteriormente.

Por último activamos el esclavo: 

MariaDB [(none)]> START SLAVE;

Explicación de parámetros del archivo my.cnf

  • log-bin: Instrucción que activa los logs.
  • server_id: Identificador del servidor. Debe ser único y no estar definido en otro grupo de replicación.
  • bind-address: Nos permite la conexión remota desde la dirección IP indicada. En este caso desde cualquiera.
  • binlog_do_db: Nombre de la base de datos que queremos replicar. En caso de no añadir este parámetro se replicarán todas las bases de datos.
  • binlog_format(ROW):Almacena en el log-bin las filas modificadas.

Automatizando tareas

Es posible que en algun momento nuestro servidor Maestro caiga, por lo tanto tenemos que poder promover el servidor esclavo a maestro. Para automatizar este proceso crearemos dos scripts mariadb_to_master y mariadb_to_slave que nos simplificarán la tarea.

Nuestro objetivo es que el esclavo se convierta en maestro y el maestro en esclavo. Para ello vamos a simular la caida del servidor maestro.

MariaDB

Promover esclavo a maestro

Deberemos crear un archivo .sh en el servidor Raspberry 2 : 

$ sudo touch mariadb_to_master.sh

Añadimos estas lineas en el archivo: 

#!/bin/bash
sql_usuario="root"
sql_password="1234"
sql_database="owncloud"
sql_args="-u$sql_usuario -p$sql_password -e"
mysql $sql_args "stop slave;"
mysql $sql_args "reset slave;"
service mariadb stop
service mariadb start
mysqldump --add-drop-table -u$sql_usuario -p$sql_password --opt owncloud > owncloud.sql
mysql $sql_args "show master status;"

Explicación del script:

Primero creamos variables para poder conectarnos a mysql. A continuación detenemos el esclavo y lo reinicimos. Por último reinicimos el servicio MariaDB, hacemos una copia de seguridad de la base de datos que se replica y ejecutamos el comando show master status para que nos lo muestre.

Le damos permisos de ejecución al archivo: 

$ sudo chmod +x mariadb_to_master.sh

Ejecutamos el script: 

$ sudo sh mariadb_to_master.sh

La salida del script debe ser similar a esta:

Salida2.png


Una vez ejecutado el script, deberemos pasar la copia de seguridad al servidor Raspberry 1: 

$ sudo scp owncloud.sql [email protected]:/home/ander

Promover maestro a esclavo

Deberemos crear un archivo .sh en el servidor Raspberry 1 : 

$ sudo touch mariadb_to_slave.sh

Añadimos estas lineas en el archivo: 

#!/bin/bash
sql_usuario="root"
sql_password="1234"
sql_database="owncloud"
sql_args="-u$sql_usuario -p$sql_password -e"
service mariadb stop
service mariadb start
mysql -u$sql_usuario -p$sql_password owncloud < owncloud.sql
mysql $sql_args "stop slave;"
mysql $sql_args "CHANGE MASTER TO MASTER_HOST='192.168.1.14', MASTER_USER= 'replicator', MASTER_PASSWORD = 'password', MASTER_LOG_FILE='$1', MASTER_LOG_POS=$2;"
mysql $sql_args "start slave;"

Explicación del script:

Primero creamos variables para poder conectarnos a mysql. A continuación reiniciamos el servicio MariaDB. Por último paramos el esclavo, le indicamos quien es su maestro y lo iniciamos. Como podemos ver, para ejecutar correctamente este script necesitamos pasarle parámetros, en concreto el nombre del log_file y su posición.

Le damos permisos de ejecución al archivo: 

$ sudo chmod +x mariadb_to_slave.sh

Ejutamos el script pasando los parámetros obtenidos del mariadb_to_master.sh: 

$ sudo sh mariadb_to_slave.sh mysqld-bin.000031 328

Owncloud

Correo

Para añadir la configuración de nuestro servidor de correo a nuestro Owncloud deberemos realizar los siguientes pasos. Priemro añadir nuestro correo personal del dominio que acabamos de crear

Add correo personal.png

Segundo paso es ir a General y añadir toda la configuración del servidor de la siguiente forma

Datos servidor correo.png

Comprobamos que el correo de prueba se envía correctamente pulsando encima de Enviar mensaje debería de aparecernos un mensaje que dice Correo electrónico enviado como podemos ver en el cliente thunderbird, nos ha llegado dicho mensaje

Thunderbird.png

Añadir y activar aplicaciones

Para añadir una aplicación que sea compatible con Owncloud deberemos hacer lo siguiente. En este caso, quiero que la gente sea capaz de registrarse sin tener que darlos de alta, para ello descargamos el siguiente plugin a nuestros servidores 

git clone https://github.com/pellaeon/registration.git

Después de descargarlo lo movemos a la la carpeta de instalación de owncloud, en mi caso será de la siguiente forma 

sudo mv registration /var/www/html/ownclouud/apps/

Una vez que hayamos movido la carpeta dentro del directorio apps, deberemos activarla y para hacerlo debemos ir a la sección de Administración y pulsar encima de Aplicaciones

Aplicaciones act.png

Dentro de Gestión de Apps pulsaremos encima de Mostrar Apps inhabilitadas

Registration owncloud.png

Pulsaremos encima de Activar e iremos a configurarla, en la misma sección de Administración iremos a Adicional Dónde pondremos las opciones que deseemos, en mi caso quedará de la siguiente forma

Ejemplo registro.png

Crear grupos usuarios

Para crear un grupo de usuarios deberemos hacer lo siguiente, iremos a Usuarios

Usuarios.png

En la nueva pantalla, solo nos quedará pulsar encima de +Agregar grupo introducir el nombre del grupo y volver a pulsar encima del símbolo +

Añadir grupo.png

Limitar espacio en disco

Por defecto, Owncloud de momento no permite la configuración de espacio en disco por grupo, por lo tanto se debe hacer manualmente. Nos dirigimos al apartado de usuarios veremos que nos aparece un apartado llamado Cuota ahí deberemos limitar el limite de GB que pueden subir los usuarios.

Obtingut de «https://wiket.esteveterradas.cat/index.php?title=Storagesis-Manual_técnico&oldid=4053»