2.2.1 Bases de datos relacionales

Es el modelo más utilizado actualmente para representar problemas reales y administrarlos de manera dinámica. El paradigma nació en 1970 de la mano de Edgar Frank Codd cuya idea es el uso de “relaciones”.

En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (que sí tenían otros modelos previos).

Para que una base de datos sea considerada relacional debe de seguir el modelo relacional, por lo que antes de introducir datos, para crear la base de datos habremos realizado los pasos necesarios para pasar del modelo entidad-relación al modelo relacional. Es por ello que hay que acordarse siempre de realizar la normalización de la base datos.

Para este tipo de bases de datos el lenguaje de consultas utilizado es el SQL (en inglés Structured Query Language; en castellano: lenguaje de consulta estructurada) el cual abordaremos más adelante.

2.2.2 No relacionales

Antes y después de la aparición del modelo relacional han existido distintos modelos de base de datos (jerárquico, de red, multidimensionales… ), por lo que hay que entender que el relacional no es el único modelo existente, aunque sí el más utilizado.

4.1.1 Un poco de historia

MySQL fue inicialmente desarrollado por MySQL AB (empresa fundada por David Axmark, Allan Larsson y Michael Widenius). MySQL AB fue adquirida por Sun Microsystems en 2008, y ésta a su vez fue comprada por Oracle Corporation en 2010.

Es cierto que aunque en sus primeras versiones carecía de características como la integridad referencial y transacciones (debido al motor MyISAM utilizado en la creación de tablas), que son características muy importantes en un SGBD (y que PostgreSQL sí tenía), no impidió que cogiera fama en los denominados entornos LAMP (Linux + Apache + MySQL + PHP).

Poco antes de la compra de Oracle, desde la comunidad libre se realizó un fork (una copia completa) del código fuente de MySQL que dió origen a MariaDB. Desde ese momento, ambos SGBD han tenido vidas paralelas, pero el origen es el mismo.

Muchas distribuciones GNU/Linux contaban con MySQL como sistema SGBD para poder ser instalado, pero a medida que el desarrollo de MariaDB fue ganando adeptos muchas distribuciones realizaron el cambio, por lo que en ciertas distribuciones no es posible instalar MySQL desde los repositorios oficiales. De hecho, algunas distribuciones mantienen el paquete MySQL pero siendo un alias para que se instale MariaDB.

Desde la compañía Percona también crearon un fork de MySQL en el que añaden mejoras creadas por ellos y también venden soporte para el mismo.

Como veremos a continuación, el no poder realizar la instalación desde los repositorios oficiales no nos impedirá tener MySQL instalado en nuestro sistema.

4.1.2 Versiones de MySQL

MySQL cuenta con distintas versiones de SGBDs que hay que conocer para saber qué versión se necesita en cada caso concreto. Nos vamos a centrar en las versiones Community (las de licenciamiento libre), pero estas versiones también cuentan con su versión con licencia comercial.

4.3.1 Sin paquete en el repositorio oficial

En caso de que nuestra distribución no cuente con el paquete en los repositorios oficiales, la instalación no será tan directa, pero eso no significa que sea difícil. La versión Community Server la podremos encontrar en su web de descarga, y desde aquí podremos descargarnos la versión que necesitemos para el sistema operativo que queramos.

En el caso de que queramos instalarlo en una distribución de GNU/Linux como Debian, Red Hat o Suse podremos hacer uso de los repositorios oficiales de MySQL para realizar la instalación. En el caso de Debian, sería:

• Descargar el paquete para poder configurar el repositorio oficial de MySQL para Debian/Ubuntu.
• Instalar el paquete:

ruben@server1:~$ sudo dpkg -i mysql-apt-config_0.8.15-1_all.deb

• Elegir en el menú que nos aparecerá:

  • En qué distribución estamos (ya que el mismo paquete sirve para Debian y Ubuntu).

    

  • Qué versión vas a querer instalar (dependiendo de la distribución y la versión en la que nos encontremos nos dejará unas versiones u otras).

    

• Instalar mysql-server (tal como veremos a continuación en Ubuntu).

4.3.2 En Ubuntu 20.04

La versión LTS de Ubuntu 20.04 cuenta con la versión 8.0 de MySQL (concretamente la 8.0.21 en el momento en el que es creado este documento).

Debido a que contamos con esta versión, que es la última versión de MySQL podremos realizar la instalación de la siguiente manera:

ruben@server1:~$ sudo apt install mysql-server-8.0

5.2.1 Conexión local (Socket)

En entornos UNIX existe la posibilidad de realizar la conexión a ciertos servidores que están en la misma máquina desde la que se origina la conexión, mediante lo que se denomina un Unix domain Socket.

Los sockets en entornos GNU/Linux se pueden ver como un fichero, y son un medio de comunicación entre procesos que se ejecutan en la misma máquina.

La configuración estándar de MySQL arranca creando un fichero Socket en la siguiente ruta por defecto /var/run/mysqld/mysqld.sock, por lo que la posibilidad de realizar una conexión local mediante dicho socket es posible.

De hecho, nada más realizar la instalación de MySQL es la única manera de poder realizar la conexión y sólo será posible desde el usuario root:

Como se puede ver, en la imagen, los pasos para poder realizar la conexión han sido:

1. Convertirnos en root
2. Ejecutar el comando mysql.

Este comando es el cliente MySQL que realizará la conexión contra el Servidor MySQL. Debido a que no se le ha pasado ningún parámetro al comando, éste realizará un primer intento de conexión a la ruta del socket estándar (indicada anteriormente).

Una vez realizada la conexión veremos que nos aparece un prompt mysql> que indica que la conexión se ha realizado correctamente y estamos en el CLI (Command Line Interface, Interfaz de Línea de Comandos) donde podremos ejecutar órdenes de configuración, administración o peticiones a las bases de datos.

5.2.2 Conexión por red (local o remota)

En la configuración inicial de MySQL también aparece la opción de poder realizar una conexión mediante el protocolo de red TCP.

root@server1:~# ss -punta | grep -i mysql
tcp   LISTEN 0      151      127.0.0.1:3306    0.0.0.0:*      users:(("mysqld",pid=765,fd=34))
tcp   LISTEN 0      70               *:33060         *:*      users:(("mysqld",pid=765,fd=31))

Los puertos de escucha son:

• 3306: Puerto que escucha únicamente en la IP 127.0.0.1
• 33060: Nuevo protocolo X (desde la versión 5.7.12) que escucha en todas las IPs del sistema.

Para poder realizar conexiones a través de estos puertos los usuarios con los que intentemos conectarnos deberán poder aceptar dicha conexión. Más adelante veremos cómo realizar estas modificaciones.

Para poder realizar esta conexión también haremos uso del comando mysql. pero esta vez sí le tendremos que pasar parámetros de conexión. Un ejemplo de cómo conectarnos a un servidor por conexión de red es:

ruben@server1:~$ mysql -u usuario -h 192.168.1.100 -p

Podemos ver que se han pasado 3 parámetros y a continuación el valor que se le pasa a cada parámetro en el comando mysql. Los parámetros son:

• -u o --user, es el usuario con el que vamos a realizar la conexión. Si no se usa éste parámetro, por defecto se le pasará el usuario con el que estamos logueados en el sistema

• -h o --host, es el servidor al que queremos conectarnos mediante conexión por red. Si no se pone este parámetro la conexión se intentará a 127.0.0.1

• -p o --password, para que nos pregunte por la contraseña de conexión del usuario. Si no se pasa este parámetro se entiende que no se va a necesitar contraseña.

5.3.1 Comprobar estado del servidor

En la instalación de MySQL se ha instalado automáticamente un servicio en Systemd que nos permitirá conocer el estado de MySQL, si está arrancado o no.

Para ello deberemos ejecutar el siguiente comando:

ruben@server1:~$ sudo systemctl status mysql

Y tras realizar la ejecución del comando, en caso de que el servicio esté arrancado veremos:

5.3.2 Arranque y parada del servidor

En caso de que queramos parar el servidor, tendremos que hacer uso de Systemd:

ruben@server1:~$ sudo systemctl stop mysql

Y para arrancarlo de nuevo:

ruben@server1:~$ sudo systemctl start mysql

5.4.1 Securizar configuración inicial

Dependiendo del método elegido para instalar MySQL la configuración inicial puede venir con usuarios o bases de datos de prueba que no nos interesan y que se pueden borrar. Para poder securizarlo tenemos el siguiente comando:

root@server1:~# mysql_secure_installation

Este script nos guiará con una serie de preguntas para securizar el servidor, que es muy utilizado en versiones anteriores, pero que no está de más ver las preguntas que nos realiza:

• “Would you like to setup VALIDATE PASSWORD component?”: Habilita el componente de validación de contraseñas, que sirve para habilitar test de fuerza de las contraseñas, y en caso de no ser lo suficientemente seguras, no se permite crear el usuario con esa contraseña.

  En versiones anteriores era un PLUGIN

  Si lo habilitamos, no preguntará qué tipo de política queremos activar sobre las contraseñas:

  • LOW: contraseñas de longitud mínima 8
  • MEDIUM: como las LOW pero con números, caracteres especiales y mayúsculas y minúsculas.
  • STRONG: como las MEDIUM pero que no se encuentren en un

• Nos pedirá la contraseña del administrador “root” de MySQL. En la instalación de Ubuntu el usuario root se conecta mediante socket, por lo que este paso no cambiará nada.

• “Remove anonymous users?”: En algunas distribuciones se crean unos usuarios anónimos, que deberían ser borrados.

• “Disallow root login remotely?”: De nuevo, en Ubuntu el usuario root sólo se puede conectar en local mediante el socket, pero en otras distribuciones es posible que root pueda conectarse por TCP desde otros servidores y/o equipos. Lo recomendable suele ser que para root no se permitan conexiones remotas.

• “Remove test database and access to it?”: MySQL suele venir con una base de datos de prueba llamada “test”. Se puede borrar.

• “Reload privilege tables now?”: Recargar los permisos de los privilegios, ya que hemos realizado cambios en las contraseñas.

5.5.1 Analizando la configuración inicial

Tal como hemos comentado previamente, los ficheros de configuración en /etc/mysql pueden estar en distintos ficheros, por lo que es recomendable echar un ojo a los ficheros que tenemos tras realizar la instalación. Vamos a analizar parte del fichero: /etc/mysql/mysql.conf.d/mysqld.cnf:

#
# The MySQL database server configuration file.
# ...
[mysqld]
#
# * Basic Settings
#
user            = mysql
# pid-file      = /var/run/mysqld/mysqld.pid
# socket        = /var/run/mysqld/mysqld.sock
# port          = 3306
# datadir       = /var/lib/mysql
bind-address      = 127.0.0.1

#
# * Fine Tuning
#
key_buffer_size         = 16M
# max_connections        = 151

#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
#
# Log all queries
# Be aware that this log type is a performance killer.
# general_log_file        = /var/log/mysql/query.log
# general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
# slow_query_log        = 1
# slow_query_log_file   = /var/log/mysql/mysql-slow.log
# long_query_time = 2
# log-queries-not-using-indexes

Como se puede comprobar, en el fichero se pueden comprobar distintos tipos de filas, y el usar un editor que realice resaltado de sintaxis nos puede ayudar a diferenciar las líneas y lo que son. Vamos a realizar una pequeña explicación de varias líneas:

• Líneas que empiezan por “#: Al igual que sucede con otros ficheros de configuración, en este caso las líneas que empiezan por almohadilla, o”#“, son comentarios. Estas líneas son ignoradas y nos pueden ayudar a comprender la estructura del fichero o podremos poner comentarios para explicar para qué sirve una directiva de configuración.
• [mysqld]: Es el comienzo de la sección, y como se ha dicho previamente, esta sección será la que se utilice al arrancar MySQL. Por lo tanto, toda directiva de configuración dentro de esta sección servirá para modificar el comportamiento por defecto del servidor.
• user: indica al servidor MySQL con qué usuario arrancará el servidor
• bind-address: dirección en la que escuchará el servidor MySQL al arrancar
• log_error: fichero donde aparecerá lo acontecido durante el arranque del servicio y en caso de haber errores nos indicará parte de la razón.

Otras variables que aparecen comentadas en la configuración inicial y por tanto el valor que tiene esa opción de configuración no tiene por qué ser la que se esté utilizando actualmente:

• pid-file: fichero donde se escribirá el PID (Process IDentificator) durante el arranque.
• socket: fichero donde está el socket.
• port: puerto en el que escucha MySQL.
• datadir: lugar donde se almacena todos los datos de las bases de datos.
• max_connections: número máximo de conexiones que aceptará MySQL
• general_log_file: lugar donde se escribe el log general en caso de estar activo.
• general_log: activar, o no, el log general. Como se puede comprobar en un comentario previo, puede suponer un problema en el rendimiento del servidor.
• slow_query_log: log de queries lentas.
• long_query_time: el tiempo mínimo para que una slow query se loguee.
• log-queries-not-using-indexes: loguear las queries que no usan índices.

Como se puede ver en estas variables de configuración, y en las anteriores, el nombre de las mismas suele ser bastante auto-explicativo, por lo que nos podemos hacer una pequeña idea de lo que pueden hacer leyendo el nombre. Eso no quita para que en caso de duda, debemos consultar el listado completo de variables que puede llegar a tener MySQL.

Como se ha comentado previamente, en caso de realizar una modificación en el fichero de configuración, tendremos que realizar un reinicio del servicio como veremos posteriormente.

5.5.2 Validando la configuración

Las variables de configuración que hemos visto hasta ahora cuentan con dos apartados:

• Nombre de la variable: puede ser una única palabra (port, socket) o varias seguidas de guión bajo (bind_address, slow_query_log).
• Valor de la variable: Es el valor que aparece a la derecha del igual (“=”) y vemos que pueden tener distintos valores: mysql, 127.0.0.1, 16M , …

Los nombres de las variables es algo que no nos podemos inventar, y es por ello por lo que deben estar bien escritas en el fichero de configuración. En caso de escribir una variable que no exista, el servidor no arrancará si hacemos un reinicio del mismo. Ejemplo:

2020-08-01T11:35:50.488392Z 0 [ERROR] [MY-000067] [Server] unknown variable 'mal=32M'

Como se puede ver en esta línea de log, hay un error al haber escrito una variable desconocida (en este caso el nombre de la variable es “mal”). Esto hace que el servidor no arranque y por tanto no se pueda acceder a él y haya una pérdida de servicio. Esto no debe suceder en un servidor en producción.

Para evitar este problema, antes de realizar cualquier reinicio del servidor, debemos asegurarnos que el fichero de configuración no contiene variables desconocidas:

root@ubuntu:/etc/mysql/mysql.conf.d# mysqld --validate-config

2020-08-01T12:02:41.763658Z 0 [ERROR] [MY-000067] [Server] unknown variable 'mal=32M'
2020-08-01T12:02:41.763689Z 0 [ERROR] [MY-010119] [Server] Aborting

Esta opción nos puede ser útil si realizamos una actualización de MySQL y en la nueva versión ya no existen variables de versiones anteriores (es raro, pero puede haber opciones obsoletas).

Esta validación de configuración no hace una comprobación exhaustiva del valor adjudicado a la variable, por lo que en caso de que la variable sea correcta pero el valor adjudicado sea erróneo, al reiniciar el servidor tendremos que comprobar el log de errores para ver qué sucede. Por ejemplo, de tener lo siguiente en la configuración:

bind-address            = 127.0.0.1z

Al intentar reiniciar, veremos el siguiente error en /var/log/mysql/error.log:

[ERROR] [MY-010255] [Server] Can't create IP socket: Invalid argument

En cambio, si otras variables tienen un valor incorrecto, el servidor arrancará, y el valor que cogerá la variable dependerá de cómo se parsea el fichero de configuración. Por ejemplo:

key_buffer_size            = 16Mz
max_connections            = -1

Para conocer qué valor pueden tener estas variables, lo mejor es ir a la documentación y mirar la variable que queremos modificar o agregar. Por ejemplo, para slow_query_log veremos que en la documentación tiene la siguiente tabla:

Esta tabla nos da mucha información acerca de la variable, ya sea para poder ver qué tipo de valor es (Boolean en este caso), su valor por defecto (OFF) y si podremos o no modificarla dinámicamente (Dynamic = Yes). El valor por defecto será el valor que obtendrá la variable si no aparece en el fichero de configuración con un valor puesto por nosotros.

Otro ejemplo, bind_address:

5.6.1 Comprobando las variables de estado (STATUS)

El listado de variables de estado nos muestra el nombre de las variables por las que podemos preguntar, el tipo de valor que pueden tener y si son globales o de sesión.

Para comprobar el estado de las variables globales del servidor:

mysql> SHOW GLOBAL STATUS;

Si nos interesa buscar por el nombre de alguna variable de la sesión y obtener su estado:

mysql> SHOW SESSION STATUS LIKE '%slow%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Slow_launch_threads         | 0     |
| Slow_queries                | 0     |
+-----------------------------+-------+
2 rows in set (0.01 sec)

5.6.2 Comprobando las variables del sistema (System)

Hemos visto que en los ficheros de configuración no están todas las variables que hemos visto en la documentación, y no tendría mucho sentido tener que estar yendo a ella para mirar qué variables tenemos y sus posibles valores por defecto. Para ver las variables globales del sistema, es obligatorio poner GLOBAL:

mysql> SHOW GLOBAL VARIABLES;

Si queremos buscar por una variable en concreto en la sesión, poner SESSION es opcional (en lugar de GLOBAL).

De no poner en qué ámbito queremos mirar las variables, se presupone que queremos ver el estado de la variable en la sesión actual.

Si queremos buscar una variable que contenga algo en el nombre podremos hacer uso de:

mysql> SHOW VARIABLES like '%slow%';
+----------------------------+---------------------------------+
| Variable_name              | Value                           |
+----------------------------+---------------------------------+
| log_slow_admin_statements  | OFF                             |
| log_slow_extra             | OFF                             |
| log_slow_slave_statements  | OFF                             |
| slow_launch_time           | 2                               |
| slow_query_log             | OFF                             |
| slow_query_log_file        | /var/lib/mysql/ubuntu-slow.log  |
+----------------------------+---------------------------------+
6 rows in set (0.01 sec)

De esta manera buscamos las variables que nos puedan interesar y vemos el valor que tienen actualmente en la sesión, para así poder ver si nos interesa cambiarlo.

También podemos hacer uso desde la línea de comandos con el comando mysqladmin, pero no tenemos tanta libertad como desde el CLI de MySQL :

root@server1:~# mysqladmin  variables

5.6.3 Modificar configuración “en caliente”

Debido a que un SGBD es un servicio crítico, no siempre podremos realizar una parada de servicio debido a un cambio de configuración. Esto afectaría a todas las conexiones que tiene establecido el servidor, y cualquier intento de consulta sería rechazado durante la parada y el arranque del mismo.

No sólo eso, ya que cuando un SGBD está en funcionamiento, guarda información en memoria RAM (a modo de caché para las peticiones más realizadas, traspasa parte de las tablas a memoria, … ) y en caso de realizar un reinicio, esa memoria se liberaría y por tanto al arrancar se debería volver a pedir los datos a disco duro, haciendo que los primeros instantes de servicio sea lento.

Por ello, se pueden realizar modificaciones de la configuración sin parar el servicio, lo que se suele denominar “hacer modificaciones en caliente”.

Bien es cierto que no todas las variables se pueden modificar de esta manera, ya que algunas son necesarias durante el arranque del servicio. Por ejemplo:

• port: no podrá ser modificada “en caliente”, ya que el puerto debe de ser algo que se necesita durante el arranque.
• bind_address: lo mismo que la anterior.
• slow_query_log: si se puede modificar en caliente.

Para conocer si una directiva puede ser modificada en tiempo de ejecución podremos ir al listado completo de variables y comprobar la columna “Dynamic”, si aparece “Yes” es que se podrá modificar. Anteriormente hemos visto cómo la variable slow_query_log tiene la opción “Dynamic” a “Yes”, por lo que se puede modificar el valor dinámicamente, y para cambiarlo haremos:

mysql> SET slow_query_log = On;
ERROR 1229 (HY000): Variable 'slow_query_log' is a GLOBAL variable
and should be set with SET GLOBAL


mysql> SET GLOBAL slow_query_log = On;
Query OK, 0 rows affected (0.01 sec)

-- alternativa
mysql> SET @@GLOBAL.slow_query_log = On;
Query OK, 0 rows affected (0.01 sec)

Como se puede comprobar, se ha intentado modificar la variable sin poner “GLOBAL”, y debido a que “slow_query_log” es una variable global, nos ha dado un error. Por eso es muy importante tener en cuenta qué tipo de variable y para qué ámbito queremos realizar la modificación. También se puede ver que la modificación se puede realizar de dos maneras.

5.6.4 Persistencia de las modificaciones

MySQL permite que estas variables que podamos hacer que estas variables persistan tras el arranque haciendo:

mysql> SET PERSIST slow_query_log  = ON;

Esto lo que hace es crear un fichero en /var/lib/mysql/mysqld-auto.cnf con formato JSON con las variables que se ha dado la orden de persistir.

Aunque resulte cómodo, se aconseja realizar la modificación de la variable en el fichero de configuración correspondiente para tener todo de manera más centralizada. Para deshacer esta persistencia:

mysql> RESET PERSIST;
Query OK, 0 rows affected (0.00 sec)

Y eliminará todas las entradas del fichero antes descrito: /var/lib/mysql/mysqld-auto.cnf.

SQL

6.2.1 Gestión de bases de datos

La función de un SGBD es la de proporcionar la capacidad de tener distintas bases de datos en el sistema, es por ello que tenemos que aprender a gestionar las bases de datos que tenemos, o en un momento dado crear bases de datos.

mysql> CREATE DATABASE prueba;

mysql> SHOW DATABASES;
+-----------------------------+
| Database                    |
+-----------------------------+
| information_schema          |
| mysql                       |
| performance_schema          |
| prueba                      |
| sys                         |
+-----------------------------+
5 rows in set (0.00 sec)

Para poder entrar en una base de datos y poder visualizar, modificar o usar las tablas y datos que hay en ella:

mysql> USE prueba;
Database changed

Borrar una base de datos existente.

mysql> DROP DATABASE prueba;

6.2.2 Gestión de tablas

La gestión de tablas se realiza cuando estamos dentro de una base de datos, por lo que deberemos asegurarnos que hemos entrado dentro de una de ellas antes de realizar ninguna gestión sobre ellas.

CREATE TABLE alumnos (
    dni      varchar(9) not null primary key,
    nombre   varchar(20),
    apellido varchar (20),
    telefono integer
);

CREATE TABLE asignaturas (
    codigo integer not null primary key,
    nombre varchar(50)
);

CREATE TABLE matriculacion_alumno (
    codigo_asignatura integer,
    dni_alumno varchar(9),
    nota float,
    fecha_matriculacion date,

    PRIMARY KEY(codigo_asignatura, dni_alumno),
    FOREIGN KEY (codigo_asignatura) REFERENCES asignaturas(codigo),
    FOREIGN KEY (dni_alumno) REFERENCES alumnos(dni) ON DELETE CASCADE
);

Si queremos modificar el modelo de la tabla creada previamente

mysql> ALTER TABLE alumnos ADD nacimiento date;

mysql> DROP TABLE alumnos;

TRUNCATE es una función especial que vacía de contenido una tabla. Realmente lo que hace es borrar la tabla y volverla a crear, de ahí que sea considerada una función dentro del DDL.

mysql> TRUNCATE TABLE alumnos;

Para poder gestionar una tabla debemos saber cómo es y cómo está creada, ya que dependiendo de ello podremos realizar modificaciones sobre la misma.

Para ver las columnas que tiene una tabla podemos hacerlo de dos maneras:

mysql> SHOW COLUMNS FROM alumnos;
mysql> DESCRIBE alumnos;

Podemos obtener más datos, como los privilegios que tenemos con el usuario que nos hemos conectado sobre cada columna haciendo:

mysql> SHOW FULL COLUMNS FROM alumnos;

Y si queremos ver cómo se ha creado la tabla:

mysql> SHOW CREATE TABLE alumnos;

6.3.1 Realizar consultas

A la hora de realizar consultas, podemos crear distintas y de distinto tipo.

mysql> SELECT * FROM alumnos;

mysql> SELECT dni, nombre, nacimiento FROM alumnos;

También podemos realizar consultas condicionales:

mysql> SELECT dni, nombre, nacimiento
            FROM alumnos
            WHERE nacimiento > '1982-01-01';

mysql> SELECT dni, nombre, nacimiento
            FROM alumnos
            WHERE nacimiento > '1970-01-01'
            ORDER BY dni ASC;

La complejidad de las consultas dependen de nuestro modelo de datos así como de los datos que queremos obtener:

mysql> SELECT a.dni, a.nombre, a.apellido, asig.nombre, ma.nota
            FROM alumnos as a, asignaturas as asig, matriculacion_alumno as ma
            WHERE a.dni = ma.dni_alumno
                AND asig.codigo = ma.codigo_asignatura
                AND ma.nota < 5
            ORDER BY a.dni ;

6.3.2 Inserción y modificación de datos

No sólo podemos realizar consultas de obtención de datos, sino que también podremos insertarlos, modificarlos o borrarlos.

mysql> INSERT INTO alumnos VALUES ('12345678Z', 'Alumno', 'Uno', '555123456','1980-01-01');

En caso de que sólo queramos insertar parte de los datos, podremos realizar:

mysql> INSERT INTO alumnos(dni,nombre) VALUES ('87654321A', 'Alumno2');

A la hora de actualizar datos, deberemos elegir qué campos queremos elegir

mysql> UPDATE alumnos SET nacimiento = '1984-01-01' WHERE dni = '87654321A';

Y a la hora de eliminar datos, podremos hacerlo de manera condicional.

mysql> DELETE FROM alumnos where dni = '87654321A';

7.1.1 Creación de usuarios

Como ya se ha explicado, es importante entender que para que la conexión sea correcta no sólo importa el usuario de conexión, sino desde donde se realiza la misma. Es por ello que a la hora de crear un usuario tendremos que conocer este dato ya que es importante. Aparte, tendremos que poner una contraseña, si es necesario, que sea lo suficientemente segura como para que pase el paso realizado en la securización inicial. A la hora de crear usuarios hay muchas opciones.

mysql> CREATE USER 'mikeldi'@'localhost' IDENTIFIED WITH auth_socket;

mysql> CREATE USER 'usuario'@'localhost' IDENTIFIED BY 'password';

mysql> CREATE USER 'usuario2'@'192.168.122.1' IDENTIFIED BY 'password';

mysql> CREATE USER 'usuario3'@'%' IDENTIFIED BY 'password';

mysql> CREATE USER 'usuario4'@'%' IDENTIFIED BY 'password' PASSWORD EXPIRE;

mysql> CREATE USER 'usuario5'@'%' IDENTIFIED BY 'password' PASSWORD EXPIRE INTERVAL 10 DAY;

7.1.2 Conexión de usuarios

Dependiendo de cómo se realice la conexión (por socket o TCP) el método de conexión será de una manera u otra.

root@server1:~# mysql

ruben@server1:~$ mysql -u usuario2 -h 192.168.122.145 -p

mysql> select user();
+------------------------+
| user()                 |
+------------------------+
| usuario2@192.168.122.1 |
+------------------------+
1 row in set (0.00 sec)

mysql> set password='password';

7.1.3 Ver los usuarios que existen

Los usuarios se guardan dentro de la tabla user en la base de datos mysql. Para poder ver los usuarios creados:

mysql> use mysql;
mysql> select * from user;

Para poder ver de otra manera los datos de los usuarios:

mysql> select * from user\G
*************************** 1. row ***************************
                 Host: %
                 User: usuario2
          Select_priv: N
          Insert_priv: N
          Update_priv: N
          Delete_priv: N
          Create_priv: N
...
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
               plugin: caching_sha2_password
authentication_string: $A$005$lq-g:Ps27zVBGU8SnP7eg7WK3qnQ6R
     password_expired: N
password_last_changed: 2020-09-05 18:22:11
...

7.1.4 Limitando los recursos de las cuentas

Las cuentas de usuarios pueden tener recursos limitados. Estos límites se pueden poner al crear un usuario:

mysql> CREATE USER 'lim1'@'localhost' IDENTIFIED BY 'frank' WITH MAX_QUERIES_PER_HOUR 20;

O se pueden añadir los límites sobre cuentas ya creadas:

mysql> ALTER USER 'usuario'@'localhost' WITH MAX_USER_CONNECTIONS 2;

mysql> ALTER USER 'usuario'@'localhost' WITH MAX_CONNECTIONS_PER_HOUR 20;

mysql> ALTER USER 'usuario'@'localhost' WITH MAX_QUERIES_PER_HOUR 500;

mysql> ALTER USER 'usuario'@'localhost' WITH MAX_UPDATES_PER_HOUR 500;

7.1.5 Borrado de usuarios

Al borrar usuarios la sentencia “DROP USER” borra una o más cuentas y sus privilegios.

Al hacer un “DROP USER”, si el usuario tiene establecida una conexión no se borrará el usuario podrá seguir haciendo peticiones. Cuando la conexión se cierre será cuando se borre el usuario, y su siguiente conexión no se podrá establecer.

Al borrar un usuario no se pierden los objetos que el usuario haya creado.

mysql> DROP USER 'usuario'@'localhost';

7.1.6 Bloqueo de usuarios

Como borrar un usuario no se puede deshacer, podría ser recomendable bloquear antes la cuenta hasta asegurar al 100% que el usuario que vamos a borrar no se va a volver a necesitar:

mysql> ALTER USER 'usuario'@'localhost' ACCOUNT LOCK;

7.1.7 Renombrar un usuario

Podemos renombrar un usuario, cambiando el usuario y el origen de la conexión. Si la cuenta ya existe obtendremos un error.

mysql> RENAME USER 'usuario'@'localhost' TO 'ruben'@'192.168.122.1';

7.1.8 Cambiar contraseña al usuario

Es interesante realizar modificaciones en las contraseñas de usuarios cada cierto tiempo.

mysql> SET PASSWORD FOR 'ruben'@'192.168.122.1' = 'password2';

7.2.1 Añadir permisos a usuarios

Existen muchos tipos de privilegios que podemos otorgar a los usuarios, y veremos una pequeña muestra de ellos.

mysql> GRANT ALL ON *.* TO 'nuevo_admin'@'192.168.1.10';

mysql> GRANT ALL ON db1.* TO 'usuario'@'localhost';

mysql> GRANT SELECT ON db1.alumnos TO 'usuario2'@'%';

mysql> GRANT INSERT ON db1.asignaturas TO 'usuario2'@'%';

mysql> GRANT ALL ON prueba.* TO 'usuario3'@'%' WITH GRANT OPTION;

7.2.2 Activar nuevos permisos

Los nuevos permisos no son aplicados hasta que no se ejecuta la siguiente sentencia:

mysql> FLUSH PRIVILEGES;

7.2.3 Eliminar permisos a usuarios

Se pueden eliminar, o revocar, permisos a usuarios:

mysql> REVOKE INSERT ON prueba.asignaturas FROM 'usuario2'@'%';

7.2.4 Visualizar permisos usuarios

Ver los permisos de nuestro usuario

mysql> SHOW GRANTS;

mysql> SHOW GRANTS FOR 'usuario2'@'%';

Copias de seguridad

8.1.1 Backup completo

Un backup completo de MySQL hará que se guarde toda la información de las bases de datos internas del sistema, en las que se incluyen los usuarios y sus privilegios.

Este sistema es el método más sencillo si queremos realizar después una restauración completa en un nuevo servidor.

root@ubuntu:~# mysqldump --all-databases > backup-completo.sql

De esta manera, le hemos indicado al script mysqldump que realice un backup de todas las bases de datos y el contenido obtenido lo vuelque al fichero backup-completo.sql. Este fichero generado es un fichero de texto que contendrá las bases de datos del sistema, usuarios, privilegios…

8.1.2 Backup de base de datos

Podemos realizar el backup únicamente de una, o varias, bases de datos que nos pueda interesar. Para poder realizar el backup de la base de datos que nos interese se hace uso del parámetro “–databases” seguido del nombre de las bases de datos, o en su forma abreviada “-B”. Los dos siguientes comandos son iguales:

root@ubuntu:~# mysqldump --databases DB1 DB2 > backup-db1-db2.sql
root@ubuntu:~# mysqldump -B DB1 DB2 > backup2-db1-db2.sql

Al crear el backup de una, o varias, base de datos de la anterior manera, en el fichero de backup nos aparecerá algo tal que:

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `DB1`;
USE `DB1`;

De esta manera, lo que nos está indicando el backup es que a la hora de restaurar, en caso de que no exista DB1 se creará previamente. Posteriormente realizará el borrado de las tablas y las volverá a crear para realizar el insert de datos.

También podremos obviar el argumento, por lo que en caso de introducir un único parámetro, lo tomará com la base de datos de la que realizar copia de seguridad.

root@ubuntu:~# mysqldump DB1 > backup-DB1.sql

Al hacer el backup de esta manera, en el fichero no aparecerá la creación de la base de datos, por lo que a la hora de realizar la importación tendremos que hacerlo sobre una base de datos ya creada.

8.1.3 Backup de una tabla

Puede darse casos que nos interese realizar backups de una única tabla, o poder hacer backups de una tabla de manera más seguida, y para ello podremos ejecutar:

De esta manera hacemos backup de la tabla “asignaturas” de la base de datos DB1.

8.2.1 Importar backups de mysqldump

Como se ha comentado previamente, mysqldump se instala junto con el servidor, y debido a que es una herramienta sencilla de usar, su importación también es sencilla. Para realizar la importación de este tipo de backups haremos uso del propio CLI mysql.

root@ubuntu:~# mysql < backup-completo.sql

root@ubuntu:~# mysql restauracion < backup-db1-asignaturas.sql

9.1.1 Scripts propios

Para realizar gran parte de los checks expuestos previamente se puede hacer uso de scripts propios, ya que pueden realizar consultas de las variables de estado para comprobar y determinar si el estado es correcto.

Un ejemplo de script creado ad hoc para nuestro sistema podría ser:

#!/bin/bash
mysql -e "SHOW STATUS LIKE 'Slow_queries';" -N | awk '{print $2}'

9.1.2 Percona monitoring tools

La alternativa a hacer uso de scripts propios es usar programas o scripts realizados por terceros, que estén ampliamente probados y que tienen detrás un equipo que quizá sea más amplio que el nuestro, y por tanto esté mejor probado.

La empresa Percona tiene un par de soluciones sobre monitorización de SGBDs (no sólo para MySQL, también para PostgreSQL y MongoDB), que son:

• Percona Monitoring and Management: Un sistema completo de monitorización, interfaz web incluída, que podremos instalar en nuestros propios servidores. Podemos ver aquí una demo.

  

• Percona Monitoring Plugins: En este caso son un conjunto de plugins (o scripts) que podremos utilizar en nuestro sistema de monitorización propio (Nagios, Centreon o Cacti). En la documentación explican cómo hacer uso de ellos.

Alta Disponibilidad

12.2.1 Configuración del servidor principal

En el fichero de configuración del servidor principal tendremos que modificarlo para que aparezca la siguiente configuración

[mysqld]
...
server-id = 1
log_bin = /var/log/mysql/binlog
binlog_expire_logs_seconds     = 2592000
max_binlog_size = 100M

Una vez modificado el fichero de configuración, el servidor debe ser reiniciado. Para comprobar si el servidor está en modo “primario” podemos consultarlo de la siguiente manera:

mysql> SHOW MASTER STATUS \G
*************************** 1. row ***************************
File: mysql-bin.000001
Position: 1397
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)

Podemos observar el fichero “mysql-bin” y la posición del mismo del servidor principal.

12.2.2 Crear usuario de replicación

Como se ha comentado previamente, el servidor réplica se conectará al principal, por lo que tiene que existir un usuario con el que poder conectarse y comprobar el estado de los binlogs.

CREATE USER 'repl'@'192.168.1.21' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.21';
FLUSH PRIVILEGES;

Hay que tener en cuenta que la IP tendrá que ser la IP del servidor réplica y será con este usuario con el que realizará la conexión. Es obligatorio poner “mysql_native_password” ya que el nuevo sistema de autenticación “caching_sha2_password” necesita de certificados para realizar la conexión.

12.2.3 Backup inicial del servidor primario/origen

Una vez configurado el servidor en modo primario, realizaremos el backup inicial que posteriormente será cargado en el servidor réplica. Debido a la configuración que hemos realizado, el servidor réplica deberá conocer a partir de qué posición del binlog obtener las modificaciones después de haberse realizado el backup. Por tanto, el backup debe realizarse de la siguiente manera:

root@server1:~# mysqldump --all-databases --source-data > dbdump.sql

Y como se puede comprobar, el parámetro nuevo es “--source-data”, que hará que dentro del fichero de backup aparezca (es posible que en el futuro aparezca como “PRIMARY” o “PRIMARY_LOG_”):

...
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1397;
...

Esta información es el punto exacto en el que se ha quedado el binlog (tanto en qué fichero como en qué posición) cuando se ha realizado el backup. Esta información la necesitaremos para posteriormente en el servidor réplica indicarle que es a partir de este punto el que deberá pedir la información a replicar.

12.3.1 Modificar configuración en el servidor RÉPLICA

En este caso, la modificación que debemos de realizar es cambiar el server-id, que tendrá que ser distinto al del primario, y podremos poner de manera opcional el nombre del servidor réplica en la variable report_host.

[mysqld]
...
server-id = 2
# la opción report_host es opcional
report_host = server2

12.3.2 Importar el backup

Tal como se realiza de cualquier backup, teniendo el backup en el propio servidor réplica:

root@server1:~# mysql < dbdump.sql

12.3.3 Configuración de conexión al primario

Desde el CLI de MySQL debemos realizar la siguiente sentencia, teniendo en cuenta:

• La IP de nuestro servidor primario.

• Los datos del usuario de replicación creado previamente.

• Los datos de binlog que hemos podido obtener del fichero de replicación.

mysql> CHANGE REPLICATION SOURCE TO
          SOURCE_HOST='192.168.1.129',
          SOURCE_USER='repl',
          SOURCE_PASSWORD='password',
          SOURCE_LOG_FILE='mysql-bin.000001',
          SOURCE_LOG_POS=1397;

14.3.1 Actualización del sistema

Por si acaso, realizaremos la actualización del índice del repositorio, actualizaremos el sistema y en caso necesario realizaremos un nuevo reinicio:

root@ubuntu:~# apt update
...
root@ubuntu:~# apt upgrade
...

Con estos comandos nos aseguramos que el sistema está actualizado a los últimos paquetes que están en el repositorio.

14.3.2 Poner IP estática

Debido a la configuración de red de nuestro servidor, la IP está puesta en modo dinámica, esto quiere decir que nuestro equipo ha cogido la IP por configuración de DHCP de nuestra red. Debido a que un servidor debe de tener IP estática, tenemos que realizar la modificación adecuada para ponerle la IP estática que mejor nos convenga. Para ello editaremos el fichero de configuración situado en la siguiente ruta: /etc/netplan/00-installer-config.yaml

Lo modificaremos para que sea parecido a (siempre teniendo en cuenta la IP y gateway de nuestra red):

network:
  ethernets:
    enp0s3:
      dhcp4: false
      addresses: [192.168.1.199/24]
      routes:
      - to: default
        via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8,1.1.1.1]
  version: 2

El fichero de configuración que hemos modificado es de tipo YAML, que es un formato de texto que suele ser utilizado en programación o en ficheros de configuración. Este tipo de ficheros tiene en cuenta los espacios para el uso de la identación, y no suele permitir el uso de tabuladores.

Para aplicar los cambios realizados en el fichero de configuración deberemos ejecutar el siguiente comando que aplicará los cambios:

root@ubuntu:~# netplan apply

15.2.1 Situación inicial: discos duros sin particionar

Como ya se ha comentado, en nuestro servidor vamos a contar con dos discos duros de igual tamaño. Esto suele ser lo habitual, pero lo importante es que las particiones que vayamos a crear sean del tamaño exacto, aunque un disco duro sea de mayor tamaño (aunque lógicamente, ese espacio quedará desaprovechado).

En la siguiente imagen vemos que tenemos dos discos duros de 15GB de tamaño cada uno:

15.2.2 Particionado inicial

A continuación vamos a tener que pensar cómo van a ser las particiones que vamos a necesitar en nuestro servidor. En nuestro caso vamos a crear dos:

• 14GB: Sistema operativo.

• 1GB: (o hasta completar) SWAP.

Como se puede entender, al tener una única partición, todo el sistema raiz “/” va a ir en ella, mientras que la otra partición será la usada para el área de intercambio.

Es importante entender que en este paso sólo vamos a crear las particiones pero sin darles formato. Por lo tanto, nuestros discos duros ahora tendrían este aspecto:

15.2.3 Crear particiones RAID

El siguiente paso es crear las particiones “virtuales” RAID. Vamos a crear una primera partición RAID que va a incluir las particiones de 14GB de ambos discos duros, y la segunda partición virtual incluirá las particiones de 1GB.

De esta manera, tendremos unas particiones MD0 y MD1 que son particiones virtuales.

15.2.4 Formatear particiones RAID con el formato adecuado

El último paso de la instalación es hacer uso de las particiones RAID creadas y formatearlas con el sistema de ficheros acorde a las necesidades que tengamos, y elegir el punto de montaje adecuado.

En nuestro caso va a ser:

• MD0: sistema de ficheros ext4 y lo vamos a utilizar como sistema de ficheros raíz “/”.

• MD1: formateado como SWAP y actuará como área de intercambio.

Tras este paso, la instalación del sistema operativo puede continuar de la manera habitual.

15.3.1 Situación inicial: discos duros sin particionar

Tal como hemos comentado previamente, en el paso 7 de la instalación, elegiremos la opción de crear un “diseño de almacenamiento personalizado”. Tras entrar en esta opción, el instalador tendrá el siguiente aspecto:

Tal como se puede ver, tenemos dos discos duros en el sistema: vda y vdb. El nombre de los discos viene de Virtual Disk, dado que la instalación la estamos realizando en una máquina virtual.

15.3.2 Particionado inicial

En este paso vamos a crear en cada uno de ellos la partición de 14GB y el resto del espacio la usaremos para la segunda partición.

15.3.3 Crear particiones RAID

El siguiente paso es crear las particiones RAID en las que haremos que el sistema cree un RAID 1 haciendo uso de las particiones de los discos duros físicos. Seleccionaremos la opción “Create software RAID (md)” y nos aparecerá una ventana en la que podremos elegir:

Crearemos primero md0 seleccionando las particiones de 14GB tal como aparece en la siguiente imagen:

Y a continuación crearemos md1 con las particiones restantes. Tal como se puede ver a continuación, las particiones de 14GB ya no aparecen, porque están siendo usadas en el otro RAID.

Tras la creación de los dispositivos “md”, nos aparecerán como dispositivos disponibles para usarlas en el siguiente paso:

15.3.4 Formatear particiones RAID con el formato adecuado

Aunque este paso lo vamos a realizar sobre las particiones RAID creadas previamente, es un paso que es habitual realizar cuando queremos que nuestra instalación tenga un sistema de particiones propio.

Tenemos que pensar que las particiones RAID ahora son como particiones normales, a las que les vamos a querer dar un formato y utilizarlas para realizar la instalación.

Vamos a seleccionar la primera, md0, posicionándonos encima de ella y dándole a “Intro” y posteriormente dándole a “Add GPT partition”:

Dejaremos el tamaño en blanco, indicando que usaremos todo el espacio libre, lo vamos a formatear con el sistema de ficheros ext4 y se va a montar como el sistema de ficheros “/”.

En md1 también le daremos a crear nueva partición, y haremos lo mismo pero usando el formato swap. Quedando una vez terminado el sistema de particiones de la siguiente manera:

Y tras esto podremos continuar la instalación de manera normal.

16.3.1 Servidor SSH

En el servidor al que nos queramos conectar deberá estar instalado el demonio/servicio SSH, conocido como sshd. Es habitual que ya esté instalado en sistemas GNU/Linux, pero de no ser así deberemos usar el sistema de paquetes de nuestra distribución para hacer la instalación. El nombre suele ser openssh-server.

Este servicio por defecto se pondrá a la escucha en el puerto 22/TCP:

ruben@vega:~$ sudo ss -pntaln
State   Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
LISTEN  0        128      0.0.0.0:22           0.0.0.0:*           users:(("sshd",pid=1122,fd=3))
LISTEN  0        128      [::]:22              [::]:*              users:(("sshd",pid=1122,fd=4))

La configuración del servicio se realiza a través de un fichero de configuración que está situado en la ruta /etc/ssh/sshd_config. Las distribuciones de GNU/Linux ya traen una configuración predeterminada que suele constar de las siguientes directivas (aunque hay muchas más):

• Port: Normalmente viene comentada, ya que el puerto por defecto es el 22. En caso de querer cambiar el puerto, podremos modificar esta línea, asegurando que no esté comentada.

• ListenAddress: Por defecto SSH se pondrá a la escucha en todos los interfaces que tengamos configurados. Si sólo nos interesa escuchar en alguna de las IPs que tengamos configuradas, deberemos modificar esta configuración.

• PermitRootLogin: Para evitar problemas de seguridad, esta directiva suele estar configurada a “No”, para evitar que se puedan usar los credenciales de root para hacer el login.

• PubkeyAuthentication: Esta directiva permite realizar la conexión a través de unas claves públicas/privadas que podemos crear. Se explicará más adelante.

Hoy día también se puede instalar en Windows 10 y posteriores a través de un comando, siendo administrador de PowerShell:

PS C:\Windows\System32> Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

PS C:\Windows\System32> Start-Service sshd

PS C:\Windows\System32> Set-Service -Name sshd -StartupType 'Automatic'

O desde el interfaz gráfico a través de las “Características opcionales”, buscando por ssh:

16.3.2 Cliente SSH

El cliente SSH es aquel programa que a través del protocolo SSH se puede conectar a un servidor SSH. Existen distintos tipos de clientes que podemos utilizar:

• CLI: El cliente de consola es el más habitual. Está instalado de forma habitual en todas las distribuciones de GNU/Linux (normalmente el paquete se llama openssh-client). También lo encontramos instalado por defecto en MacOS.

Hoy día también está instalado en Windows 10, y de no estar, se puede instalar a través de las “Características Opcionales”.

• GUI: Existen distintos interfaces gráficos que nos puede interesar utilizar:

  • Putty: Un cliente muy habitual en entornos Windows.
  • Kitty: Una versión mejorada del anterior.
  • Termius: Cuenta con versión de escritorio y móvil.

Para realizar la conexión al servidor SSH debemos conocer:

• Dirección del servidor: Ya sea mediante IP o nombre FQDN (fully qualified domain name) que se resuelva.
• Puerto: Ya hemos comentado que por defecto el puerto es 22.
• Usuario: Para realizar el sistema de autenticación, necesitamos un usuario que exista en el sistema.
• Contraseña: Los credenciales de acceso del usuario.

Para realizar la conexión desde un cliente de consola ejecutaremos:

ruben@vega:~$  ssh usuario@192.168.1.200 -p 22

En el comando anterior podemos identificar:

• ssh: el cliente de consola

• usuario: el nombre del usuario con el que nos queremos conectar al servidor remoto.

• @: la arroba en inglés significa “at”, que indica “usuario en el servidor X”.

• 192.168.1.200: La IP del servidor al que nos queremos conectar.

• -p 22: Estos dos parámetros van juntos, “-p” indica que vamos a indicar el puerto de conexión y “22” que nos queremos conectar a ese puerto. Debido a que 22 es el puerto por defecto, podríamos no poner estas opciones si sabemos que el servidor escucha en el puerto 22.

Si realizamos la conexión a través de un cliente de interfaz, como es putty, el aspecto será el siguiente, donde sólo podremos introducir la IP del servidor. Cuando se comience con la conexión nos pedirá los credenciales de acceso.

Si es la primera vez que nos conectamos a un servidor mediante SSH nos saldrá un mensaje como el siguiente:

ruben@vega:~$  ssh usuario@192.168.1.200 -p 22

The authenticity of host '192.168.1.200 (192.168.1.200)' can't be established.
ECDSA key fingerprint is SHA256:uK9MOl0gLDhTtCrlcafc1zVObVA/vnOMn6TWFsQb23o.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Este “key fingerprint” es un identificador que está relacionado con el fichero de “clave pública” del servidor. Es como el DNI del servidor. La primera vez se nos guarda ese fingerprint, y en caso de que en una próxima conexión varíe, nos avisará. No suele ser habitual que este identificador cambie.

16.3.3 Conexión mediante certificados de clave pública/clave privada

Existe una alternativa a la hora de realizar una conexión SSH para que no nos pida la contraseña del usuario, y es hacer uso de los certificados de clave pública y clave privada. Este concepto de “clave pública y clave privada” viene de la criptografía asimétrica.

Este sistema de criptografía asimétrica hace uso de dos claves que están asociadas entre sí:

• Clave privada: Es la base del sistema criptográfico, y como su nombre indica, se debe de mantener en privado. Nunca se debe de compartir, ya que entonces se podrían hacer pasar por nosotros.

• Clave pública: Asociada a la clave privada, la clave pública puede ser compartida y enviada a otros ordenadores para poder realizar la conexión.

Para generar el par de claves se realiza con el siguiente comando:

ruben@vega:~$  ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ruben/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Your identification has been saved in /home/ruben/.ssh/id_rsa
Your public key has been saved in /home/ruben/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:SPqPOYBmPb8PCFhcZgqcWZPZzaL5RNfMeKmHqebvC7E ruben@vega
The key's randomart image is:
+---[RSA 3072]----+
|o +oB o = .      |
| * B.+ = *       |
|  + + + =        |
| o o + = .       |
|. .o+.o S        |
|  +.+*o          |
| o  +Eo          |
|     .+=         |
|      *B+        |
+----[SHA256]-----+

El comando muestra los siguientes pasos:

1. Creación de la pareja de claves pública/privada haciendo uso del sistema criptográfico RSA.
2. Lugar donde se va a guardar la clave privada. Por defecto en ~/.ssh/id_rsa.
3. Contraseña para securizar la clave privada. De esta manera, para poder usarla habrá que introducir dicha contraseña. Dado que nosotros queremos evitar introducir contraseñas, lo dejaremos en blanco.
4. Lugar donde se va a guardar la clave pública. Por defecto en ~/.ssh/id_rsa.pub

Una vez tenemos nuestro par de claves, podemos copiar la clave pública al usuario del servidor que nos interese mediante el siguiente comando:

ruben@vega:~$  ssh-copy-id user@servidor_remoto

Para ello es imprescindible conocer previamente la contraseña del usuario en el servidor. El comando ssh-copy-id realizará una conexión SSH y copiará el contenido de la clave pública, ~/.ssh/id_rsa.pub, dentro del fichero ~/.ssh/authorized_keys del usuario en el servidor remoto. Este paso se puede realizar a mano (con un editor de texto).

Al realizar la siguiente conexión, ya no necesitaremos introducir la contraseña del usuario, ya que el sistema remoto podrá autenticarnos a través del sistema clave pública/privada.

16.3.4 Crear túneles SSH

Una de las funcionalidades extra de SSH es la posibilidad de crear “túneles” para securizar protocolos no seguros, o poder acceder a servicios que sólo escuchan en localhost.

Pongamos como ejemplo el siguiente escenario:

Tenemos un servidor web con Apache y MySQL al que queremos acceder. Por seguridad MySQL sólo está escuchando en localhost (127.0.0.1), por lo que el acceso al servicio MySQL no es posible. Para administrarlo nos tenemos que conectar al servidor, y realizarlo de manera local.

En este punto es donde entra en juego la creación de un túnel seguro al servidor, para poder acceder al servicio remoto. Para ello es imprescindible poder realizar una conexión SSH (ya sea mediante usuario o clave pública/privada).

Para crear un túnel, desde el equipo de escritorio, lanzaremos el siguiente comando:

ruben@vega:~$  ssh usuario@192.168.1.200 -L 6306:127.0.0.1:3306 -N

Al ejecutar este comando, habremos creado un túnel que enlaza el puerto remoto 3306 (que sólo se escucha en el “127.0.0.1” del servidor), con el puerto local 6306 del equipo de escritorio. A continuación la explicación del comando y sus parámetros:

• “ssh usuario@192.168.1.200”: es como una conexión SSH normal. Lo que estamos indicando es que queremos conectarnos con “usuario” al servidor remoto 192.168.1.200 a través de SSH.

• -L 6306:127.0.0.1:3306: Especifica que el puerto local especificado se va redirigir al puerto e IP remota. Para entender esto hay que separar dos partes de los parámetros:

  • 6306: Especifica la IP y el puerto local. En este caso, antes del puerto no hemos especificado IP, por lo que se creará un puerto 6306 que sólo se pone a la escucha en localhost en el equipo de escritorio
  • 127.0.0.1:3306: Esta es la dirección y puerto remoto al que nos queremos conectar. En este caso, es el puerto 3306 que está escuchando en la IP 127.0.0.1 del servidor.

• -N: Sirve para que no ejecute ningún comando en el servidor remoto, y por tanto no nos abrirá conexión de terminal.

A nivel visual, y para entender de mejor manera lo realizado, sirva la siguiente imagen y los pasos que se pueden dar en un escenario real:

Con una aplicación en el equipo de escritorio queremos conectarnos al servidor MySQL que sólo escucha en el servidor remoto. Ejecutamos el túnel visto anteriormente, y los pasos que podremos realizar son los siguientes:

0. Mediante una aplicación nos podemos conectar al puerto local 6306, que ha sido creado mediante el comando anterior. Este puerto local está redirigido al puerto del servidor remoto. Por lo tanto la conexión se securiza a través del túnel
1. Como el túnel está establecido, la conexión viaja de manera segura a través de él.
2. Al llegar al servidor remoto, sabe que la conexión debe ir al puerto 3306 de la IP 127.0.0.1, que es lo establecido en el comando.
3. La conexión vuelve al túnel.
4. Viaja por el túnel hasta llegar a la comunicación que se había establecido previamente.

De esta manera, hemos podido realizar una conexión a un servicio remoto a través de SSH y completamente seguro.

Este es un caso especial de túnel, similar a lo explicado previamente. En lugar de querer realizar una conexión a un servicio del equipo al que nos conectamos, en este caso lo usaremos de salto para acceder a otro servidor.

En este caso estando en casa nos queremos conectar a un equipo de la oficina. No tenemos VPN, y no hay redirección de puertos directa, pero podemos acceder al firewall perimetral. Por lo tanto, lo podemos utilizar para saltar al servidor que nos interesa.

En este caso, el comando a ejecutar sería:

ruben@vega:~$  ssh usuario_firewall@84.85.86.87 -L 2222:172.17.1.200:22 -N

De esta manera, ahora desde nuestro equipo podremos realizar una conexión SSH al puerto 2222 que realmente será una redirección que viaja a través del túnel hasta el firewall, y que a su vez redirige al puerto 22 del servidor 172.17.1.200.

17.2.1 Conocer los datos y la importancia de los mismos

Para saber sobre qué datos tenemos que realizar las copias de seguridad, debemos conocer los datos que manejamos en la empresa, la importancia que tienen y su ubicación. Ejemplo: no es lo mismo la importancia de los datos gestionados en la base de datos de clientes, o el directorio “Descargas” el PC de un usuario.

También tendremos que conocer el tamaño actual de esos datos, y saber cuánto volumen total alcanzan. Cuanto mayor tamaño tengan, también mayor será el espacio ocupado por las copias de seguridad.

Otro aspecto a tener en cuenta es saber las modificaciones que sufren esos datos, y estimar el volumen de esos cambios. Ejemplo: no es lo mismo que una base de datos reciba 10 clientes nuevos al día o que reciba 15.000 ventas a la hora en nuestra tienda online.

17.2.2 Espacio ocupado por la copia de seguridad

Estimar el espacio que nos va a ocupar una copia de seguridad puede parecer sencillo, pero no siempre es así, y es por eso que conocer los datos, tal como hemos dicho antes, es de vital importancia.

Tendremos que tener en cuenta cuánto ocupan nuestros datos originales, cuál va a ser la estrategia de backup a utilizar, estimar el incremento de espacio que puede haber en los datos originales…

Por lo tanto, siempre deberíamos estimar por alto el espacio ocupado, y siempre pudiendo realizar la expansión de ese espacio “en caliente”, para que las copias de seguridad funcionen cada día.

17.2.3 Punto mínimo en el tiempo que queremos recuperar

Es posible tener copias de seguridad que estén completamente actualizadas en cuanto se realizan cambios en los datos originales, pero la puesta a punto de estos sistemas puede no estar a nuestro alcance (por no conocer cómo se realizan o por un coste elevado).

En ciertos casos, algunas empresas pueden aceptar la pérdida de ciertos datos, ya que el gestionar que las copias se realicen “en tiempo real” es más caro que el repetir el proceso de crear esos datos de nuevo.

Ejemplo: Una empresa puede no necesitar hacer backup de la base de datos de cuándo fichan los empleados en tiempo real, porque si se pierden los datos de un día es asumible (el backup se hace cada noche). En cambio, la base de datos de marketing tiene que realizarse en tiempo real.

17.2.4 Punto máximo en el tiempo que queremos recuperar

Otro aspecto importante a tener en cuenta es pensar cuánto tiempo para atrás queremos poder llegar para poder realizar la restauración de los datos. No será lo mismo querer realizar una restauración de los datos de hace una hora, un día, de hace una semana o de hace un año, ya que esta decisión influirá en toda estrategia de copia de seguridad.

Es por eso, que a los datos hay que darle la importancia que se merece, y es bastante probable que distintos datos tengan distintos puntos de restauración máximo.

Ejemplo: No es lo mismo los datos de facturación de una empresa, que la ley nos marca que debemos guardar dichos datos (4 años), los datos de una página web que apenas cambia (igual nos sirve una copia a la semana) o la carpeta personal de un usuario en su equipo (dado que en su equipo no debería guardar nada importante de la empresa, se podría asumir una pérdida de datos).

17.2.5 Ubicación de la copia de seguridad

Es muy importante también tener en cuenta cuál va a ser la ubicación de la copia de seguridad y las consecuencias que eso puede conllevar. Vamos a poner varios ejemplos:

• Si decidimos hacer la copia de seguridad en el mismo equipo informático, un problema de electricidad podría suponer la pérdida de los datos originales y los backups.

• Si decidimos realizar la copia de seguridad en la misma sala de ordenadores donde se sitúan los datos originales, si esa sala se ve involucrada por un factor que destruya todo (un incendio, un robo, …), perderíamos todos los datos.

• Si decidimos realizar la copia en la misma oficina, edificio, puede pasar lo mismo que el punto anterior

• Si decidimos realizar la copia en la “nube”, el tiempo para realizar la copia de seguridad y el tiempo de restauración de los datos puede incrementarse

• Si decidimos realizar la copia en otra oficina, dependemos de la conexión, los datos deberían ir cifrados, tiempo de creación de la copia de seguridad y restauración…

Como se puede ver, cada ejemplo puede tener unos pros y unos contras.

17.2.6 Tiempo estimado de la copia

Teniendo en cuenta lo comentado previamente, el tiempo estimado de la copia de seguridad es muy importante, y es posible que varíe en el tiempo. No es lo mismo realizar la copia de seguridad de unos pocos megabytes o de varios gigabytes.

Es por eso por lo que tendremos que tener en cuenta el tiempo que tarda en realizarse nuestras copias de seguridad para así asegurar que se realizan de manera correcta y no se solapan en el tiempo.

17.2.7 Plan de recuperación ante desastre

Tan importante es tener una copia de seguridad como un plan ante un posible desastre. De nada sirve tener una copia de seguridad si restaurarla nos va a llevar semanas por no saber el estado de las mismas, o si su restauración es compleja.

Por lo tanto, es muy importante disponer de un plan de recuperación ante desastres que esté actualizado, que contemple si ha habido modificaciones en la gestión de copias de seguridad, que tenga en cuenta los pasos a realizar…

Este plan de recuperación debería ser puesto en práctica cada cierto tiempo para asegurar que sigue estando vigente, y si no, realizar las modificaciones oportunas.

El plan de recuperación ante desastre debería contener:

• Los distintos métodos y estrategias de copias de seguridad que existen en la empresa

• Ubicaciones donde se realizar las copias de seguridad

• Importancia de los datos de los que se realizar la copia de seguridad

• Cómo realizar la restauración de cada sistemas de los que se ha realizado la copia de seguridad

• Orden para realizar las restauraciones y dada la importancia de los datos, la prioridad de las restauraciones

• ...

17.2.8 Tiempo estimado de recuperación de los datos

El último punto, pero no por ello menos importante, es el tiempo estimado de recuperación de los datos.

Es por eso que tenemos que conocer el tiempo estimado de recuperación de los datos para poder gestionar los tiempos con los empleados, los clientes…

Este tiempo estimado, al igual que el tamaño de las copias, puede variar en el tiempo, por lo que debemos asegurar cada cierto tiempo el realizar simulacros para asegurar qué tiempos se manejan.

Teniendo en cuenta el gráfico anterior:

RTO:

es el objetivo de tiempo de recuperación (Recovery Time Objective), y es el tiempo que se tarda en restablecer el servicio, o al menos los mínimos acordados. Cuanto menor sea el tiempo de recuperación, mejor.

RPO:

es el objetivo de punto de recuperación (Recovery Point Objective), y es el último instante de tiempo previo al incidente al que los sistemas son capaces de regresar. Habitualmente suele ser marcado por la frecuencia con que se realicen las copias de seguridad. De nuevo, cuanto más cercano a T=0 mejor.

17.3.1 Copiar los ficheros

Sería la metodología más sencilla. Simplemente haremos una copia de los datos importantes en otra ubicación/soporte. Este sistema hace que cada X tiempo, se guarden los ficheros y obtendremos una copia completa de los datos.

El problema es que no tendremos la posibilidad de recuperar un fichero en un estado anterior a la última copia. Es decir, si se realiza la copia de seguridad a las 6:00 de la mañana, no podremos obtener el estado del fichero previo a ese. Si a las 11:00 el usuario corrompe el fichero, podríamos recuperar al estado de las 6:00, pero no al estado de ayer.

17.3.2 Sistema incremental a nivel de bloque

Se basa en copiar sólo los bloques físicos que han sido modificados. Tendremos que tener guardado el fichero original por un lado, y a partir de ahí sólo guardaremos las modificaciones de manera incremental.

Para recuperar el fichero, primero tendremos que elegir restaurar el fichero original completo, y posteriormente aplicar los bloques incrementales hasta llegar al punto de restauración que nos interesa.

17.3.3 Sistema incremental o diferencial binaria

Similar al anterior, pero esta vez en lugar de hacer uso de bloques (1K, 4K, 8K…), la parte incremental o diferencial sería a nivel binario.

17.3.4 Versionado de ficheros

El versionado de ficheros se puede realizar de distintas maneras:

• Utilizando el sistema de ficheros: Existen sistemas de ficheros que cuando uno es modificado, automáticamente crea una versión nueva del mismo.

• Versionado manual: cuando el usuario quiere crear una nueva versión del fichero, debe ejecutar a mano una acción para guardar la nueva versión del mismo.

17.4.1 Multi-backup completos

Este método sería el más sencillo, pero también el que más espacio nos ocuparía, y posiblemente el que más tiempo puede tardar, dependiendo de los datos a copiar.

En este método, podríamos hacer una copia completa de los datos que queremos guardar en tantas ubicaciones como queramos. Supongamos que queremos poder llegar a restaurar hasta 3 días de un fichero corrupto, eso supondría que tendríamos que tener 3 ubicaciones distintas donde cada día haríamos un backup completo de los datos. Por ejemplo:

• Ubicación 1: el lunes haríamos el primer backup completo

• Ubicación 2: el martes haríamos el segundo backup completo

• Ubicación 3: el miércoles haríamos el tercer backup completo

• Ubicación 1: el jueves haríamos el backup completo (machando los datos previos que había del lunes)

• …

Como se puede ver, es una estrategia cíclica, sencilla, y que en ciertos casos puede ser más que suficiente. Pero como se ha comentado previamente, cada día se realizará un backup completo, por lo que habrá que tener en cuenta el tiempo que tarda, el espacio que ocupa, ...

17.4.2 Incrementales y/o diferenciales

Normalmente es el método más habitual y todos los programas suelen tener estos métodos a la hora de realizar copias de seguridad.

El hacer uso de copias incrementales y/o diferenciales nos permitirá poder restaurar los datos hasta un punto concreto. Por eso será muy importante tener en cuenta cuánto tiempo queremos poder llegar a restaurar, porque no es lo mismo a la hora de estimar espacio ocupado, si queremos restaurar los datos de una semana, de hace un mes o de hace un año.

Por lo tanto, a la hora de utilizar esta metodología, como ya se ha comentado, que es la más habitual, la estimación de espacio debe de ser holgada, y pensar a futuro, en cuánto puede llegar a aumentar el espacio ocupado.

17.4.3 Estrategia personalizada

Como se ha comentado previamente, pueden existir tantas estrategias como entornos existan, por lo que dependiendo de nuestros datos, nuestro entorno, nuestro modelo de negocio, tendremos que crearnos una estrategia propia.

Este método puede ser el más complejo, ya que quizá tengamos que realizarlo a mano, pero con ello nos aseguraremos de darle la importancia que se merece a cada parte de los datos que tengamos que realizar un backup.

17.4.4 La que el programa nos marque

Si hacemos uso de un programa de gestión de backups, al final estaremos limitados a lo que el programa nos permita. Como se ha comentado, la estrategia incremental/diferencial suele ser la más ampliamente utilizada, por lo que casi todos los programas deberían tener esta opción.

Dependiendo del programa, nos permitirá hacer mezclas de estrategias, realizar copias a sistemas remotos (la nube, por FTP, SSH…), varios cada día… Por lo que quedaría en nuestra mano analizar distintos programas y ver cuál es el que mejor se adecúa a nuestras necesidades.

18.2.1 Monitorización básica

Tal como se ha comentado, en los servidores se suele realizar una monitorización del estado del mismo que suele ser común para todos, por lo que lo habitual suele ser tener una plantilla genérica para todos los servidores con la que se monitorizará:

• Cantidad de RAM utilizada

• Cantidad de memoria virtual utilizada

• Carga de la CPU

• Espacio libre en las unidades de disco duro

• Estado del sistema RAID del servidor (en caso de tenerlo)

• Cantidad de usuarios conectados a la máquina

• Estado de puertos de conexión (SSH, por ejemplo)

• Latencia hasta llegar al servidor

• …

Es cierto que no será lo mismo monitorizar un sistema GNU/Linux o un sistema Windows (ya que puede variar alguno de las comprobaciones a realizar), pero el estado general que queremos conocer es el mismo. Por lo tanto, lo habitual es tener dos plantillas, una específica para servidores Windows y otra para GNU/Linux.

18.2.2 Monitorización de Servicios

Aparte de la monitorización básica comentada previamente, necesitaremos monitorizar el estado de los servicios que pueda tener el servidor propiamente dicho. Para ello, de nuevo, se crearía una plantilla específica para cada tipo de Servicio que podamos tener en nuestro servidor.

No será lo mismo monitorizar un servidor que tenga un servidor web, un servidor de base de datos, un proxy… O puede que el servidor cuente con todos esos servicios.

Es por eso que a la hora de realizar la monitorización de un servidor es muy importante conocer qué funciones desempeña cada servidor en la infraestructura a la que pertenece y analizar los servicios que tiene arrancados para posteriormente ser monitorizados.

18.3.1 Monitorización pasiva

En la monitorización pasiva el servidor (u objeto monitorizado) es el encargado de mandar la información de manera periódica al servidor central. El agente instalado se ejecutará como una tarea programada cada cierto tiempo (habitualmente unos pocos minutos) e informará de la situación cambiante, de haberla, al servidor central.

Esta manera de monitorización es utilizada también cuando no hay un servidor central. En este caso, si la comprobación ha sido incorrecta, podría mandar un mail al administrador del servidor.

18.3.2 Monitorización activa

Suele ser la manera habitual de proceder de los sistemas que cuentan con un servidor centralizado de monitorización. El servidor de monitorización se encarga de preguntar al servidor, a través de la conexión con el agente, por la comprobación de alguno de los checks, y el agente devuelve la información.

A continuación se puede observar las etapas que existen en un sistema de monitorización activa utilizando un servidor de monitorización central:

Las etapas serían:

0. El sistema de monitorización tiene un scheduler (o planificador) que decide cuándo tiene que realizar cada comprobación (normalmente, cada pocos minutos).

1. El servicio encargado de monitorizar establece conexión con el agente remoto y le pide que compruebe un estado. En este ejemplo se ha optado por la RAM.

2. El agente en el servidor que se quiere monitorizar recibe la notificación y realiza una comprobación local (normalmente llamando a scripts locales) para obtener la cantidad de RAM ocupada, total y libre que tiene

3. El agente envía al sistema de monitorización el resultado obtenido en la ejecución de los scripts del paso anterior.

   1. El monitorizador al recibir el resultado, lo coteja con los rangos de baremación que tiene y decide si el check está en estado OK, Warning o Critical.

   2. Lo habitual es que si el resultado del servicio no es OK, se ejecute en el servidor de monitorización algún tipo de alarma (ya sea enviar un mail, sistema de mensajería, … ) para notificar a los administradores.

4. El sistema de monitorización guarda en una base de datos los resultados obtenidos para así poder realizar posteriores análisis o comprobaciones temporales de los mismos.

5. Esos datos se suelen visualizar en una interfaz web, tal como hemos visto previamente.

Estos pasos son ejecutados de manera continuada en el servidor de monitorización para cada comprobación que se realiza en cada uno de todos los servidores que se monitorizan. Por lo tanto, se entiende que el propio servidor de monitorización también tiene que ser monitorizado ya que es de vital importancia que su estado sea óptimo.

18.3.3 Monitorización centralizada

Como ya se ha comentado, es el sistema habitual de monitorización. Las ventajas que podemos obtener al hacer uso de este sistema son muchas, pero se pueden destacar las siguientes:

• Monitorización centralizada: Aunque parezca obvio, el tener un único sistema en el que concentrar toda la información es muy útil y eficaz.

  • La alternativa sería tener una monitorización distinta en cada servidor.

• Interfaz web: Hoy en día suele ser habitual que los sistemas de monitorización tengan un servicio web en el que visualizar todos los datos obtenidos.

• Sistema de plantillas: De nuevo, es lo habitual, lo que hace que la gestión de monitorización de servidores sea más cómoda.

• Gestión de usuarios: Podremos tener usuarios que puedan ver unos servidores u otros, por lo que podemos tener equipos especializados en distintos grupos de monitorización y que sólo se enfoquen en ellos.

  • Esto también es útil para dar acceso a los clientes a la monitorización de sus propios servidores.

18.3.4 Monitorización reactiva

La monitorización reactiva se puede definir como el sistema de monitorización que no sólo se encarga de comprobar y recibir el estado de los servidores, si no que también reacciona a los mismos para tratar de solucionar los problemas encontrados. Tras esta definición está la idea de que existen ciertos fallos recurrentes que no siempre necesitan la intervención humana para solucionarse, y que por tanto, se puede tratar de ejecutar antes de que sea considerado un problema real.

Como ejemplo sencillo se puede poner el espacio libre en disco duro. Imaginemos que se comprueba que apenas hay espacio en el disco duro de un servidor. En este caso, el sistema de monitorización recibirá que el servidor está al 99.95% de espacio ocupado, y por tanto, en lugar de notificar a un humano indicando el estado crítico, el sistema reacciona de manera automática tratando de liberar espacio. Se habrá configurado previamente que en la reacción de este error trate de borrar ficheros temporales, vaciar papelera, limpiar ficheros de caché de ciertas rutas … Una vez hecho esto, se volverá a comprobar el estado del servidor. Si el espacio ocupado en disco duro ha bajado y está en modo OK no habrá que hacer nada más, y se habrá evitado que un administrador tenga que realizar dicha tarea. Si por el contrario el estado sigue siendo incorrecto, el sistema notificará el error para que se realice un análisis y se solucione el problema.

Como ejemplo extremo (que no suele ser habitual configurarlo así), imaginemos que la RAM consumida por un SGBD es muy alta y esté poniendo en peligro el estado del servidor, se podría configurar para que el sistema reaccione reiniciando el SGBD para que libere la RAM y vuelva a prestar servicio.

19.2.1 Configuración de Apache

La configuración para que Munin se pueda ver a través del servidor web Apache se encuentra en el fichero de configuración /etc/munin/apache24.conf. Normalmente esta configuración ya está aplicada en el Apache tras realizar la instalación, y se puede ver que existe un enlace simbólico, que si seguimos desde /etc/apache2/conf-enabled/munin.conf nos llevará al fichero mencionado previamente.

Esta configuración permite ver la web de Munin pero sólo si estamos conectados desde el propio servidor, a modo de seguridad sólo permite conexiones desde “localhost”. Esto no suele ser lo habitual en servidores, por lo que vamos a modificar la configuración para poder acceder a esta web desde cualquier IP.

Para ello, modificaremos el fichero arriba mencionado y modificaremos las líneas donde aparece “Require” y pondremos “Require all granted”. Tras realizar la modificación de la configuración de Apache, deberemos reiniciar el servicio:

root@vega:~# systemctl restart apache2

Y tras esto, ya deberíamos poder ir al navegador web y poniendo http://IPSERVIDOR/munin (donde IPSERVIDOR es la IP del servidor que acabamos de configurar) y ver el interfaz de Munin:

20.2.1 Adaptador puente

Es el tipo de adaptador que se usará si queremos que las máquinas virtuales aparezcan en la red física como si fueran un equipo más. Para poder entenderlo de mejor manera, podríamos pensar que este tipo de adaptador lo que hace es crear un “switch virtual” entre las máquinas virtuales y el interfaz físico, por lo que es como si fueran un equipo más en la red física.

Si el equipo físico anfitrión cuenta con más de un NIC (por ejemplo, en un portátil el NIC por cable y el NIC wifi) tendremos que elegir en la máquina virtual sobre qué NIC queremos hacer el puente. En la siguiente imagen en el desplegable sólo se puede seleccionar un interfaz porque el equipo sólo cuenta con un NIC físico.

Es el método utilizado cuando virtualizamos servidores, ya que podrán dar sus servicios a toda la red.

20.2.2 NAT

Cada máquina virtual contará con su propio “router virtual” que hará NAT, y por eso todas las máquinas virtuales que usen este modo suelen tener la misma IP, pero no pertenecen a la misma red. Por defecto no se puede realizar conexión desde la red física al equipo virtualizado.

20.2.3 Red interna

Este tipo de adaptador lo que hace es “crear” un “switch virtual” que unirá las distintas máquinas virtuales que estén conectadas al nombre de esa red interna.

En el siguiente ejemplo la VM1 tiene 2 NICs, cada una con una red interna distinta. La VM2 tiene un NIC conectado a una de las redes internas creadas previamente y VM3 está conectada a la otra red interna.

Virtualbox no se encarga de dar IPs en estas redes, por lo que deberemos configurar cada interfaz de la máquina virtual con el direccionamiento que nos interese.

Este método se utiliza si queremos comunicar máquinas virtuales entre sí y que estén aisladas, ya que no podrán conectarse con el exterior, ni siquiera con el propio equipo físico.

20.2.4 Red NAT

Podría definirse como una mezcla de NAT y red interna. Las máquinas virtuales podrán pertenecer a una única red, se podrán comunicar entre ellas, estarán detrás de un NAT de la red física y se podrán comunicar con el exterior.

Para poder usar ese modo hay que crear la “red NAT” en Virtualbox yendo a “Archivo → Preferencias → Red” y ahí se creará las redes NAT que queramos con el direccionamiento interno que nos interese.

A la hora de crear la máquina virtual y elegir la opción “Red NAT” se podrá elegir entre las redes creadas en el paso anterior.

20.2.5 Adaptador sólo-anfitrión

Este tipo de adaptador es similar al de “red interna” pero con la posibilidad de comunicarse con el equipo físico anfitrión. En el equipo físico se crea un interfaz virtual y a través de él se podrá comunicar con las máquinas virtuales.

El direccionamiento que existe entre las VMs y el host se define en Virtualbox, dentro de “Archivo → Administrador de red de anfitrión”. Las máquinas virtuales podrán coger IP de ese direccionamiento por DHCP.

Mismo uso que “red interna” pero añadiendo la opción de comunicarnos con el host anfitrión.