2.2.1 Elección del idioma

El primer paso del asistente será elegir el idioma principal que usaremos en el sistema operativo. Antes de realizar la descarga de la ISO hemos elegido el idioma español, por lo que el asistente nos aparecerá por defecto en ese idioma. Podremos elegir:

2.2.2 Elección del sistema operativo

Windows Server 2022 tiene distintos modos a la hora de ser instalado, tal como podemos ver en la siguiente captura de pantalla del proceso de instalación:

Existen dos opciones principales a la hora de elegir, ya que cada una de ellas permitirá instalarlo con o sin experiencia de escritorio. Las opciones principales son:

• Standard Evaluation: Útil para empresas medianas o pequeñas, que no requieran de grandes sistemas de virtualización.
• Datacenter Evaluation: No habrá límite a la hora de crear máquinas virtuales con un host Hyper-V por cada licencia.

Existen más diferencias, y es por eso que Microsoft tiene una página dedicada con la comparación de ambas versiones. Por lo tanto, antes de realizar la instalación para nuestro sistema, debemos realizar una estimación de los requisitos para así poder elegir de manera adecuada.

Nosotros vamos a elegir la versión “Standard Evaluation” con experiencia de escritorio ya que podremos realizar la configuración desde el propio servidor. Dependiendo del caso, habrá que analizar cuál es la mejor opción antes de realizar la instalación.

Al darle a “Siguiente” nos aparecerán los términos de la licencia.

2.2.3 Tipo de instalación

Tras aceptar la licencia nos aparecerá el tipo de instalación que deseamos realizar:

• Actualización: Para realizar actualizaciones sobre sistemas compatibles ya instalados.
• Personalizada: Tal como indica la imagen anterior, los archivos, las configuraciones y las aplicaciones no se migran. En caso de realizar una instalación nueva (como en nuestro caso), utilizaremos esta opción.

Debemos tener en cuenta cuál es la situación en la que nos encontramos y decidir cuál es la mejor opción de las que se nos ofrece. Por eso es importante realizar la lectura de cada opción que nos aparece en todos los pasos de la instalación. Y más cuando se trata de la instalación de un sistema operativo de servidor

2.2.4 Particionado de discos duros

Dado que nuestra máquina virtual es nueva, y no tiene ningún sistema operativo previo, vamos a tener que realizar la instalación en el disco duro que se ha añadido a la máquina virtual.

Dependiendo del tamaño que hayamos elegido, o incluso los discos duros que tengamos, nos aparecerán en la nueva pantalla del programa de instalación.

2.2.5 Terminar el proceso de instalación

2.2.6 Personalizar la configuración

Al terminar el proceso anterior, el último paso nos permitirá realizar la configuración de la contraseña del usuario Administrador.

Tal como se puede ver a continuación, el nombre de usuario no podrá ser modificado, y nos pedirá la contraseña y la confirmación de la contraseña.

Cabe recordar que esta contraseña es muy importante, ya que con ella realizaremos la configuración de todo el sistema, y por tanto debe ser una contraseña segura y debemos guardarla a buen recaudo. Al darle a “Finalizar” el servidor se reiniciará.

3.1.1 Active Directory

Active Directory (AD), o Directorio Activo, son los términos que utiliza Microsoft para referirse a su implementación de servicio de directorio en una red distribuida de computadores. Utiliza distintos protocolos, principalmente LDAP, DNS, HDCP y Kerberos.

De forma sencilla se puede decir que es un servicio establecido en uno o varios servidores en donde se crean objetos tales como usuarios, equipos o grupos, con el objetivo de administrar los inicios de sesión en los equipos conectados a la red, así como también la administración de políticas en toda la red.

Su estructura jerárquica permite mantener una serie de objetos relacionados con componentes de una red, como usuarios, grupos de usuarios, permisos y asignación de recursos y políticas de acceso. (Fuente: wikipedia).

3.1.2 Dominio

Un dominio es una colección de objetos dentro del directorio que forman un subconjunto administrativo. Pueden existir diferentes dominios dentro de un bosque, cada uno de ellos con su propia colección de objetos y unidades organizativas.

Para poner nombre a los dominios se utiliza el protocolo DNS. Por este motivo, Active Directory necesita al menos un servidor DNS instalado en la red

3.1.3 Unidad Organizativa (UO)

En inglés Organizational Unit (OU). Es la unidad jerárquica inferior al dominio que puede tener objetos y/u otras UO. Más adelante las usaremos para la creación de GPOs.

3.1.4 Objeto

La palabra Objeto se utiliza como nombre genérico para referirnos a cualquiera de los componentes que forman parte del directorio, como una impresora o una carpeta compartida, pero también un usuario, un grupo, etc. Incluso podemos utilizar la palabra objeto para referirnos a una Unidad organizativa.

Cada objeto dispondrá de una serie de características específicas (según la clase a la que pertenezca) y un nombre que permitirá identificarlo de forma precisa. En general, los objetos se organizan en tres categorías:

• Usuarios: identificados a través de un nombre (y, casi siempre, una contraseña), que pueden organizarse en grupos, para simplificar la administración.
• Recursos: que son los diferentes elementos a los que pueden acceder, o no, los usuarios según sus privilegios. Por ejemplo, carpetas compartidas, impresoras, etc.
• Servicios: que son las diferentes funciones a las que los usuarios pueden tener acceso. Por ejemplo, el correo electrónico.

3.1.5 Controlador de dominio

Un Controlador de Dominio (domain controller) contiene la base de datos de objetos del directorio para un determinado dominio, incluida la información relativa a la seguridad. Además, será responsable de la autenticación de objetos dentro de su ámbito de control.

En un dominio dado, puede haber varios controladores de dominio asociados, de modo que cada uno de ellos represente un rol diferente dentro del directorio. Sin embargo, a todos los efectos, todos los controladores de dominio, dentro del mismo dominio, tendrán la misma importancia.

3.1.6 Árbol

Un Árbol es simplemente una colección de dominios que dependen de una raíz común y se encuentran organizados como una determinada jerarquía. Dicha jerarquía también quedará representada por un espacio de nombres DNS común.

De esta forma, sabremos que los dominios empresa.com e informatica.empresa.com forman parte del mismo árbol, mientras que empresa.com y linux.com no.

Si un determinado usuario es creado dentro de un dominio, éste será reconocido automáticamente en todos los dominios que dependan jerárquicamente del dominio al que pertenece.

3.1.7 Bosque

El Bosque es el mayor contenedor lógico dentro de Active Directory, abarcando a todos los dominios dentro de su ámbito. Los dominios están interconectados por Relaciones de confianza transitivas que se construyen automáticamente (consultar más adelante el concepto de Relación de confianza). De esta forma, todos los dominios de un bosque confían automáticamente unos en otros y los diferentes árboles podrán compartir sus recursos.

Como ya hemos dicho, los dominios pueden estar organizados jerárquicamente en un árbol que comparte un espacio de nombres DNS común. A su vez, diferentes árboles pueden estar integrados en un bosque. Al tratarse de árboles diferentes, no compartirán el mismo espacio de nombres.

3.1.8 Relaciones de confianza

En el contexto de Active Directory, las Relaciones de confianza son un método de comunicación seguro entre dominios, árboles y bosques. Las relaciones de confianza permiten a los usuarios de un dominio del Directorio Activo autenticarse en otro dominio del directorio.

3.4.1 Tipos de implementación

En el primer paso a la hora de configurar Active Directory aparecen tres opciones distintas que debemos de entender antes de proceder con la configuración. En la siguiente pantalla aparecen las tres opciones:

• Agregar un controlador de dominio a un dominio existente: lo utilizaremos cuando queramos tener Alta Disponibilidad en nuestra infraestructura, ya que el nuevo servidor actuará de réplica del servidor que actúe de controlador actualmente.
• Agregar un dominio a un bosque existente: cuando necesitemos añadir un nuevo dominio (para realizar diferenciación a otro que ya tengamos instalado) a un bosque ya existente.
• Agregar un nuevo bosque: Utilizado para realizar instalaciones nuevas creando un nuevo dominio.

3.4.2 Nombre de dominio raíz

A la hora de elegir un dominio para nuestro Active Directory existen varias opciones:

• Elegir un TLD (Top Level Domain) válido, registrado a tu empresa. Ejemplo: miempresa.com
• Usar un subdominio de un TLD válido. Ejemplo: corp.miempresa.com Usar un TLD no válido. Ejemplo: miempresa.local, miempresa.corp, …
• En principio, y salvo que tengamos una razón para ello, elegiremos la primera opción y le daremos al botón de “Siguiente”.

Dado que estamos realizando una instalación nueva, utilizaremos la última opción.

3.4.3 Opciones del controlador de dominio

En el siguiente paso de configuración del Active Directory tendremos distintas opciones que debemos entender para proceder a su configuración:

Los niveles funcionales determinan las funcionalidades disponibles de dominio o bosque de Active Directory, y determinan los sistemas operativos Windows Server que se pueden ejecutar en los controladores. Normalmente, deberíamos elegir las últimas versiones disponibles para poder utilizar el mayor número de características posibles. En caso de que necesitemos compatibilidad con versiones anteriores, entonces elegiremos la versión correspondiente.

También nos va a pedir la contraseña de restauración de servicios de directorio DSRM. Con ella podremos iniciar sesión cuando no se esté ejecutando el servicio de Active Directory, ya sea porque se ha detenido o porque hemos tenido que iniciar en modo DSRM el servidor.

3.4.4 Otras opciones

Una vez realizado el paso anterior, y tras darle a “Siguiente”, nos aparecerán nuevos pasos que podremos pasarlos sin realizar modificaciones, ya que las configuraciones por defecto se corresponden al dominio que hayamos introducido o rutas donde se almacena la información. El último paso será para revisar y realizar la instalación:

Tras estos pasos revisaremos las opciones y le daremos a “Instalar”.

5.1.1 Tipos de grupos

Windows Server admite dos tipos de grupos:

• Distribución: Se usa para crear listas de distribución de correo electrónico. Sólo se pueden usar con aplicaciones de correo electrónico (como Exchange Server) para enviar correo electrónico a colecciones de usuarios. Los grupos de distribución no tienen seguridad habilitada.

• Seguridad: Se usan para proporcionar de manera eficaz la asignación del acceso a los recursos de la red. Con los grupos de seguridad se pueden asignar derechos de usuario a grupos de seguridad en Active Directory permisos a grupos de seguridad de recursos.

5.1.2 Ámbito de grupos

Los grupos se caracterizan por un ámbito que identifica el grado en el que se aplica el grupo en el árbol de dominios o en el bosque. El ámbito del grupo define dónde se pueden conceder permisos al grupo. Los siguientes tres ámbitos de grupo se definen mediante Active Directory:

• Dominio Local: Sólamente se puede otorgar permisos sobre los recursos que se sitúan en el dominio donde está ubicado el grupo de dominio local.

• Global: Puede otorgar permisos sobre los recursos de cualquier dominio del bosque, o dominios de confianza.

• Universal: Puede otorgar permisos sobre cualquier dominio del mismo bosque o de bosques de confianza.

5.1.3 Grupos de seguridad predeterminados

Los grupos predeterminados, como el grupo administradores del dominio, son grupos de seguridad que se crean automáticamente al crear un dominio en Active Directory. Se pueden utilizar estos grupos predefinidos para controlar el acceso a los recursos compartidos y para delegar roles administrativos específicos para todo el dominio.

A muchos grupos predeterminados se les asigna automáticamente un conjunto de derechos de usuario que autorizan a los miembros del grupo a realizar acciones específicas en un dominio, cómo iniciar sesión en un sistema local o realizar copias de seguridad de archivos y carpetas. Por ejemplo, un miembro del grupo operadores de copia de seguridad tiene el derecho de realizar operaciones de copia de seguridad para todos los controladores de dominio del dominio.

Los grupos predeterminados se encuentran en el contenedor Builtin y en el contenedor usuarios de usuarios y equipos de Active Directory.

5.1.4 Crear un grupo para usuarios

Windows Server ya trae una serie de grupos creados por defecto y cada uno de ellos cuenta con sus características.

Para crear un grupo propio tendremos que ir a “Usuarios y equipos de Active Directory”, seleccionar Users y hacer click derecho para elegir “Nuevo”:

Al darle a la opción “Grupo” tal como aparece en el menú desplegable, nos aparecerá una nueva ventana donde podremos elegir el nombre del grupo y las opciones comentadas previamente: qué “Ámbito de grupo” queremos que sea y el “Tipo de grupo”:

Tras poner las opciones que mejor nos convenga, nos aparecerá el nuevo grupo, al que posteriormente podremos añadir usuarios.

5.2.1 Usuarios predeterminados

Cuando se crea el dominio, se crean también dos nuevas cuentas:

• Administrador: Tiene control total sobre el dominio y no se podrá eliminar ni retirar del grupo Administradores (aunque sí podemos cambiarle el nombre o deshabilitarla).

• Invitado: Está deshabilitada de forma predeterminada y, aunque no se recomienda, puede habilitarse, por ejemplo, para permitir el acceso a los usuarios que aún no tienen cuenta en el sistema o que la tienen deshabilitada. De forma predeterminada no requiere contraseña, aunque esta característica, como cualquier otra, puede ser modificada por el administrador.

5.2.2 Agregar cuenta de usuario no-administrador

Para crear un nuevo usuario, por ejemplo user1, tendremos que elegir dónde lo queremos guardar. Haremos igual que con el grupo, click derecho y elegir la opción “Usuario” en este caso:

Al seleccionar la opción de “Usuario”, nos aparecerá una nueva ventana donde podremos rellenar:

• Nombre de inicio de sesión de usuario: El nombre que el usuario deberá introducir al encender el ordenador y aparecer la pantalla de inicio de sesión.

  El nombre de inicio de sesión no debe repetirse.

• Nombre de inicio de sesión de usuario (Anterior a Windows 2000): Debería coincidir con el nombre de inicio de sesión.

Tras darle a “Siguiente” nos aparecerá la pantalla donde debemos introducir:

• Contraseña: La contraseña que el usuario deberá introducir al iniciar sesión.

• Confirmar contraseña: Debe coincidir.

Y aparecen cuatro opciones que podemos marcar dependiendo de lo que necesitemos:

• Que no expire la contraseña, ya que por defecto caducan pasados 42 días.

• Deshabilitar la cuenta.

Al darle a “Siguiente” nos aparecerá el último paso que será el de confirmar la creación del usuario.

6.2.1 Añadir una unidad de red a usuarios

Es habitual que en una red los usuarios tengan que conectarse a unidades de red. Los usuarios finales no tienen por qué saber cómo conectarse a una unidad de red, y por tanto si les facilitamos el trabajo será más fácil que puedan acceder. En una red con Active Directory podemos indicar que los usuarios tengan distintas unidades de red conectadas en el equipo y con una letra correspondiente en el momento en el que se loguean.

Para el ejemplo se ha creado una Unidad Organizativa llamada “Usuarios” y dentro otra llamada “Sistemas” y dentro tenemos un usuario llamado “sysadmin1” que hemos añadido al grupo “sistemas”:

6.2.2 Permitir conexiones ping

Es habitual que los equipos Windows 10 no permitan realizar conexiones del protocolo ICMP (ping) ya que el firewall las rechaza. Por otro lado, para tener controlado los equipos que están encendidos en la red es interesante que esté habilitado.

Dado que ir configurando equipo a equipo el firewall es una tarea tediosa, el realizar la configuración de manera automática mediante una GPO es sencillo y nos permite ver cómo podemos realizar configuraciones que en este caso afectan al equipo y no al usuario.

Al llegar a este punto, haremos click derecho y le daremos a “Nueva regla” y vamos a seguir el asistente de creación de una nueva regla personalizada que permita el protocolo ICMPv4 de entrada desde cualquier equipo.

Una vez creada la GPO se aplicará cuando los equipos reinicien. Para evitar tener que reiniciar al crear nuevas GPO, vamos a crear la siguiente GPO que permitirá la administración del equipo de manera remota.

6.2.3 Administración remota de equipos

Tal como hemos dicho anteriormente, las GPOs no se aplican de manera inmediata, y dependiendo de si son de equipo o de usuario se deberá reiniciar o cerrar sesión.

Para poder actualizar las GPOs de manera remota vamos a crear una GPO que va a permitir la conexión desde el servidor a los equipos y que permitirá recibir la orden de actualizar las GPOs entre otras cosas. Para tener ordenados los equipos, vamos a crear una “OU” llamada “equipos” y dentro de ella otras “OU” para cada departamento que queramos. Los equipos que tengamos en la red los deberemos ordenar en estas Unidades Organizativas creadas, y de esta manera podremos mandar la actualización a los equipos que nos interese.

Vamos a crear una nueva GPO llamada “Permitir actualizar GPOs desde servidor” y la vamos a crear en la “OU” de “equipos”.

La ruta para crear es: “Configuración del equipo → Directivas → Plantillas Administrativas → Red → Conexiones de red → Firewall De Windows Defender → Perfil de dominio → Firewall de Windows Defender: permitir excepción de administración remota entrante”, la cual habilitaremos pero sólo permitiendo la IP de nuestro servidor. El resumen de la GPO sería el que aparece en la imagen:

Para aplicar esta GPO el equipo remoto deberá reiniciarse. A partir de este momento, cuando ya se haya aplicado la GPO podremos forzar la actualización de las GPO desde el servidor desde el propio “Administrador de directivas de grupo”, haciendo click derecho sobre la OU donde están los equipos que nos interesa y dando a “Actualización de directiva de grupo”

Tras confirmar que queremos actualizar las directivas para el número de equipos que estén en esa Unidad Organizativa, nos aparecerá un mensaje de confirmación de que el proceso se ha realizado de manera correcta:

Debemos fijarnos que en la columna central no aparece ningún código de error. Este proceso hará que las GPOs se recarguen en una tarea que se va a ejecutar en el equipo remoto en los próximos 10 minutos. Si queremos que sea inmediato podemos forzar la actualización mediante un comando en powershell.

También podremos administrar los equipos desde el programa de “Usuarios y equipos de Active Directory”, eligiendo el equipo que queramos y darle a “Administrar”:

Lo que nos abrirá el asistente de administración remota:

Y desde aquí podremos realizar parte de la administración remota del equipo.

6.2.4 Habilitar acceso al escritorio remoto

En una red no siempre tenemos acceso a los equipos de los usuarios, por encontrarse en otras sedes, oficinas o situaciones geográficas. Es por esto por lo que el poder acceder a los equipos de los usuarios supone una ventaja administrativa a nivel global.

Para ello, podemos crear una GPO para que los equipos que están en nuestro Active Directory se les active el acceso remoto para poder así conectarnos a ellos.

Los pasos a dar cuando creamos la GPO son:

1. Habilitar escritorio remoto: “Configuración del equipo → Directivas → Plantillas administrativas → Componentes de Windows → Servicios de Escritorio remoto → Host de sesión de Escritorio remoto → Conexiones → Permitir que los usuarios se conecten de forma remota mediante Servicios de Escritorio remoto”

   

2. Habilitar el acceso en el firewall al puerto necesario (RDP, que es 3389). Existe una plantilla para ello en: “Configuración del equipo → Directivas → Plantillas administrativas → Red → Conexiones de Red → Firewall de Windows Defender → Perfil de dominio” y aceptar conexiones desde la IP del servidor.

   

   Por defecto sólo los usuarios administradores pueden realizar conexiones de acceso remoto.

3. Si queremos que cualquier otro usuario que no sea el Administrador pueda realizar conexiones mediante escritorio remoto, crearemos un grupo nuevo, por ejemplo “escritorio remoto”.

   Este grupo debe ser admitido en los equipos remotos dentro del grupo local “Usuarios de escritorio remoto”. Esto lo haremos a través de la GPO utilizando la directiva: “Configuración del equipo → Preferencias → Configuración del Panel de control → Usuarios y grupos locales”. Hacemos click derecho, para crear nuevo grupo local, y seleccionaremos:

   • Nombre de grupo: Usuarios de escritorio remoto (integrado).

   • Miembros: El nuevo grupo que hemos creado

11.1.1 El nacimiento de Unix

1964-1969

Los laboratorios Bell empiezan un proyecto con el MIT (Instituto Tecnológico de Massachusetts) y General Electric para desarrollar un sistema de tiempo compartido (“time-sharing computing”): se llamaría Multics (Multiplexed Information and Computing Service).

Hasta este momento, los sistemas utilizados eran de un único proceso, la CPU no era compartida por múltiples procesos sino que se ejecutaba por lotes (se les mandaba los procesos a ejecutar y se ejecutaban en orden).

Multics obtuvo licencia libre en el 2007. En Diciembre del 2016 salió la última versión 12.6f.

1969

Uno de los desarrolladores de Multics, Ken Thompson, decidió escribir su propio sistema operativo. Ken Thompson es conocido también por crear el lenguaje de programación B, el sistema de codificación de caracteres UTF-8 y el lenguaje de programación Go, entre otras cosas.

A Ken Thompson se le une Dennis Ritchie y otros, y empiezan a programar un sistema de ficheros jerárquico, el concepto de procesos de computación, ficheros de dispositivos, un intérprete de comandos, … El resultado de lo programado era más pequeño y simple que Multics, lo que se convertiría en Unix. En Agosto ya tendrían el sistema operativo, se auto-gestiona, tenía un assembler, un editor y una shell de comandos.

Dennis Ritchie es conocido también por crear junto con Ken el lenguaje de programación C (aparece por primera vez en 1972).

1970

En ese momento el nuevo sistema operativo se llamaba Unics (Uniplexed Information and Computing Service, un juego de palabras en contraposición a Multics). No tenían todavía dinero de la organización en el desarrollo (era desarrollado por los programadores) y tampoco era multitarea todavía.

A finales de año el sistema ya era conocido como UNIX, y se había portado a la máquina PDP-11.

Las primeras versiones de Unix incluían el código fuente para que las universidades lo pudiesen modificar y así poder extenderlo a sus necesidades.

1971

El sistema se empieza a hacer complejo y como querían que más usuarios lo usasen, crean el sistema de manuales que es utilizado hoy en día (mediante el comando “man”).

1973

La versión 4 del sistema es reescrita completamente en C. Hasta este momento el sistema había estado escrito en ensamblador, por lo que no era portable entre distintos tipos de máquinas, aunque la primera versión portada a otra plataforma fue en 1978. Se cree que había “más de 20” instalaciones del sistema.

1974

La versión 5 se licencia para ser utilizada en instituciones educativas.

1975

La versión 6 se licencia para poder ser utilizadas por empresas por $20.000 de la época.

1977

La universidad de Berkeley lanza su primera versión de Unix bajo la Berkeley Software Distribution (BSD).

1979

Con la salida de Unix v7, se comienza a portar a los distintos “microordenadores” de la época y a los distintos microprocesadores (Motorola 68000, Intel 8086, … ).

1980

Microsoft anuncia su primer Unix para microcomputadoras de 16 bits (Xenix).

11.1.2 El nacimiento de GNU (GNU’s Not Unix)

1971

Richard Stallman comienza su carrera en el MIT en el laboratorio de inteligencia artificial.

Es conocido no sólo por el movimiento GNU, si no también por crear GCC y Emacs entre otra gran cantidad de software.

En esa época el software se distribuía de manera abierta para poder ser modificado. Lo habitual era realizar modificaciones para mejorar el software y distribuirlo entre compañeros y universidades.

1982

Richard Stallman quiere modificar el firmware de unas impresoras y el fabricante le pide que firme un acuerdo de no divulgación si le enseñan el código. Esto hace que Stallman se enfurezca y es cuando decide que la situación actual debe cambiar y volver al sistema de intercambio de software anterior.

1983

Se anuncia el nacimiento del proyecto GNU, cuya finalidad es la de construir un sistema operativo completamente libre, compatible con Unix. La idea es dar a los usuarios la libertad y el control de sus ordenadores.

1985

Se lanza el manifiesto GNU, y ya cuenta con un editor de texto (Emacs), compilador de C, una shell, varias utilidades … El núcleo inicial todavía no es funcional.

1986

Richard Stallman escribe y publica la definición de lo que es Free Software (Software Libre) a través de la Free Software Foundation.

Más adelante veremos a qué se refiere sobre libertad en el software.

11.1.3 El nacimiento de Minix

1987

Andrew S. Tanenbaum crea Minix como propósito educativo y para enseñar cómo funciona un sistema operativo.

1991

Sale la versión 1.5 de Minix y es portada a distintas arquitecturas (IBM, Motorola 68000, Amiga, Apple Macintosh, …).

1992

Debate con Linus Torvalds sobre la arquitectura del kernel Linux (núcleo monolítico) en lugar de usar un micronúcleo.

11.1.4 El nacimiento de Linux

1991

Un estudiante en la universidad de Helsinki, Linus Torvalds, comienza un proyecto personal escrito para su nuevo ordenador, un PC con procesador 80386.

El desarrollo comienza bajo Minix, usando el compilador GCC del movimiento GNU (GCC = GNU Compiler Collection).

El proyecto termina convirtiéndose en un kernel de un sistema operativo y escribió al grupo de noticias de Minix diciendo:

“Hola a todos los que estáis ahí fuera usando minix.

Estoy haciendo un sistema operativo (libre), (solamente por aficion, no será grande ni profesional como el GNU) para clones 386(486) AT.

…

PD. Sí – está libre de cualquier código de minix, y tiene un sistema de ficheros multi-hilo. NO es portable (usa el cambio de tareas del 386 etc), y probablemente nunca soporte otra cosa que no sean los discos duros AT, porque es todo lo que tengo :-(. ”

1992

Originalmente la licencia de Linux era propia e impedía el uso comercial de Linux. En la versión 0.99 esto cambia y se cambia a la licencia GNU Public License (GPL).

1993

El proyecto cuenta con más de 100 desarrolladores. El kernel se adapta al entorno del proyecto GNU. Nace la distribución Debian (una de las más importantes a día de hoy)

1994

Se libera la versión 1.0. El proyecto XFree86 se une y Linux consigue interfaz gráfico. Nacen las primeras distribuciones comerciales Red Hat y Suse.

1998

Empresas como IBM, Compaq y Oracle anuncian que apoyan a Linux. Nace el interfaz gráfico KDE.

1999

Nace el interfaz gráfico GNOME como reemplazo a KDE, ya que KDE hacía uso de una librería propietaria en aquel momento (QT).

2001

Steve Ballmer (CEO de Microsoft) dice: “Linux es un cáncer”.

2002

Se libera OpenOffice (originalmente suite ofimática de Sun Microsystems). Nace Mozilla (hoy día: Firefox).

2003

IBM lanza un anuncio para la Linux Foundation: https://www.youtube.com/watch?v=x7ozaFbqg00

2004

Nace Ubuntu (basándose en Debian) y Steve Ballmer (CEO de Microsoft) dice que Linux infringe muchas de sus patentes.

2008

Nace Android, sistema operativo con kernel Linux. Actualmente es el sistema operativo de móviles que más terminales tiene.

2009

Red Hat iguala a Sun Microsystem en capitalización bursátil (un gran logro simbólico).

2014

Satya Nadella (CEO de Microsoft) muestra en una presentación la siguiente transparencia:

2016

Microsoft anuncia WSL (Windows Subsystem for Linux) y se puede instalar en Windows 10 y Windows Server 2019. Permite correr ejecutables de Linux nativamente.

11.1.5 Cronograma de sistemas Unix

En el siguiente cronograma se puede ver la línea temporal de los sistemas Unix:

12.1.1 Copyleft y GNU Public License (GPL)

Es una práctica legal que consiste en el ejercicio del derecho de autor (copyright en inglés) con el objetivo de propiciar el libre uso y distribución de una obra, exigiendo que los concesionarios preserven las mismas libertades al distribuir sus copias y derivados (Wikipedia).

Con esto nació la licencia GNU GPL, la cual permite al usuario final la libertad de usar, estudiar, compartir y modificar el software recibido. Tiene que quedar claro que un programa comercial puede ser Software Libre.

12.1.2 Diferencias con el Open Source

Los programas Open Source son aquellos que podemos ver el código fuente pero esto no quiere decir que podamos modificarlo o adaptarlo a nuestras necesidades.

El Open Source es menos restrictivo que el Software Libre y se puede decir que todo Software Libre es Open Source, pero no todo Open Source tiene por qué ser libre.

12.1.3 Licencias libres más conocidas

Un listado de las licencias libres más utilizadas (en la Wikipedia existe una tabla comparativa):

• GNU GPL

• BSD

• MIT

• Licencia Apache

• Licencia PHP

• Creative Commons (no todas las versiones). Más utilizadas en contenido multimedia.

13.3.1 Almacenamiento permanente

Si queremos que un disco duro nuevo sea permanente en nuestro sistema, podremos montarlo en cualquier lugar de la estructura jerárquica. Debido a este sistema, el usuario final no se tendrá que preocupar en almacenar los ficheros en una ruta distinta, si no que será el administrador el que haya hecho que esa ruta ahora pertenezca a un disco duro nuevo.

Imaginemos que el sistema operativo se ha instalado en un disco duro pequeño de 32Gb de espacio y se está llenando, y el directorio que más ocupa es el directorio de los usuarios. Podremos añadir al servidor un nuevo disco duro montado en /home y por tanto a partir de ahora los datos guardados en /home estarán en un nuevo disco duro más grande.

root@vega:~# lsblk
NAME                       MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                          8:0    0   1,8T  0 disk
└─sda1                       8:1    0   1,8T  0 part /home/backup

sdb                          8:16   0   3,6T  0 disk
└─sdb1                       8:17   0   3,6T  0 part /home/disco4tb
sdc                          8:32   0 447,1G  0 disk
├─sdc1                       8:33   0   529M  0 part
├─sdc2                       8:34   0   100M  0 part
├─sdc3                       8:35   0    16M  0 part
└─sdc4                       8:36   0 446,5G  0 part
nvme0n1                    259:0    0 931,5G  0 disk
├─nvme0n1p1                259:1    0   512M  0 part
└─nvme0n1p2                259:2    0   800G  0 part /home
nvme1n1                    259:3    0 931,5G  0 disk
├─nvme1n1p1                259:4    0   512M  0 part /boot/efi
├─nvme1n1p2                259:5    0    90G  0 part /
├─nvme1n1p3                259:6    0   300G  0 part
│ ├─VMs-ubuntu--20.04--so1 254:0    0    10G  0 lvm
│ ├─VMs-manjaro            254:2    0    20G  0 lvm
│ └─VMs-win10              254:3    0    35G  0 lvm
└─nvme1n1p4                259:7    0 156,2G  0 part

14.3.1 Permisos especiales

Existen otros permisos especiales:

• SUID: permiso especial que permite que el fichero sea ejecutado con los permisos del dueño del fichero (aunque lo ejecute otro usuario). Se visualiza con una “S” en el permiso de ejecución del dueño -rwsrw-r-- .

• SGID: permiso especial que permite que el fichero sea ejecutado como el grupo. Aparece una “S” en el permiso de ejecución del grupo: -rwxr-s---.

• STICKY: si el bit sticky está activado en un directorio sólo el usuario root, el dueño del directorio o el dueño del fichero puede borrar ficheros dentro de dicho directorio. Aparece una “t” en el permiso de ejecución del resto de usuarios:drwxrwxrwt. Muchas distribuciones usan este permiso en el directorio /tmp

14.3.2 Cambiando permisos y dueños a los ficheros y a los directorios

Para cambiar los permisos a los ficheros y a los directorios se hace con el comando chmod.

Para cambiar permisos de dueño a los ficheros y a los directorios se hace con el comando chown.

14.4.1 Configurando “sudoers”

Los permisos de sudo se realizan en el fichero /etc/sudoers , y para su edición se hace uso del comando visudo, el cual abre el fichero y se asegura que a la hora de guardar la sintaxis es correcta.

Si realizamos cualquier modificación sobre el fichero, éste será tenido en cuenta la próxima vez que se realice la ejecución del comando “sudo”, por lo tanto, no hay que realizar ningún reinicio de servicio.

El fichero /etc/sudoers tiene permisos de sólo lectura para el usuario root y el grupo root:

root@vega:# ls -lh /etc/sudoers
-r--r----- 1 root root 669 jun  5  2017 /etc/sudoers

Un fichero sudoers suele tener el siguiente aspecto:

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

La línea que más importa en este fichero es la que indica “%sudo ALL=(ALL:ALL) ALL” y es explicada en su comentario anterior. Lo que quiere decir es que cualquier usuario que pertenezca al grupo “sudo” podrá realizar cualquier comando del sistema como superusuario. La sintaxis de la línea es:

• %sudo: cualquier usuario que pertenezca al grupo “sudo”

• ALL= : desde cualquier host o IP

• (ALL:ALL): el usuario que ejecuta puede ejecutar el comando como cualquier usuario y cualquier grupo

• ALL: puede ejecutar cualquier comando

Un ejemplo limitando el uso de sudo a un único comando a un usuario:

ruben    ALL=(ALL:ALL) NOPASSWD:/bin/systemctl suspend

Con esta línea lo que estamos permitiendo es que el usuario “ruben” puede ejecutar el comando “/bin/systemctl suspend” (suspender el equipo) y sin necesidad de meter contraseña al hacer sudo, gracias a la opción “NOPASSWD”).

14.5.1 Variables de entorno

En cualquier sistema operativo existen las denominadas “variables de entorno”. Son variables que cada usuario tiene y sirven para indicar ciertos parámetros que se están utilizando (la SHELL que se está usando), o parámetros que se van a usar a la hora de ejecutar comandos o realizar tareas, ya que se consultan a ellas. En GNU/Linux las variables de entorno se pueden consultar ejecutando:

ruben@vega:~$ printenv
LANG=es_ES.utf8
LOGNAME=ruben
XDG_VTNR=2
COLORTERM=truecolor
PWD=/home/ruben
DESKTOP_SESSION=gnome
USERNAME=ruben
SHELL=/usr/bin/zsh
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
...

Una variable de entorno puede consultarse haciendo:

ruben@vega:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Como se puede ver, es con un “$” y el nombre de la variable en mayúsculas. Existen muchas variables de entorno, y podríamos crear las nuestras propias si así lo necesitáramos.

14.5.2 La importancia de “su -”

Con el comando “su” nos podemos convertir en cualquier otro usuario del sistema siempre y cuando conozcamos su contraseña. Hay que notar la diferencia respecto a “sudo” que cuando lo ejecutamos nos pide nuestra contraseña.

Al ejecutar “su” nos convertimos en el usuario root (o ejecutando “su usuario2”, nos convertimos en el usuario2), pero no hacemos uso de sus variables de entorno, si no que seguimos con las variables de entorno del usuario que éramos previamente. Para convertirnos en el usuario y que obtengamos sus variables de entorno es necesario ejecutar “su -”, o lo que es lo mismo: “su -l”, que el manual nos dice: “Start the shell as a login shell with an environment similar to a real login”. Por ejemplo:

ruben@vega:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

ruben@vega:~$ su
Contraseña:

root@vega:/home/ruben# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

root@vega:/home/ruben# exit

ruben@vega:~$ su -
Contraseña:

root@vega:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

El usuario “ruben” tiene unos valores en la variable de entorno PATH (es la variable que se encarga de tener las rutas de los ejecutables de los programas). Al convertirse en root haciendo uso de “su”, y mirar la variable PATH, podemos observar que es igual que el usuario prueba.

Ahora bien, si a la hora de convertirse en root hace uso de “su -”, se puede ver cómo la variable PATH obtiene otros valores, siendo lo más significativo que aparecen las rutas “/usr/local/sbin” y “/usr/sbin” que son las rutas donde se almacenan los ejecutables que (en principio) sólo deberían ejecutarse como administrador del sistema.

15.1.1 SMB/CIFS

Server Message Block (SMB) y Common Internet File System (CIFS) son protocolos de red desarrollados para compartir archivos e impresoras entre nodos de una red. El protocolo SMB fue desarrollado originalmente por IBM y posteriormente ampliado por Microsoft y renombrado como CIFS.

Los términos SMB y CIFS son a menudo intercambiables pero hay características en la implementación de SMB de Microsoft que no son parte del protocolo SMB original. Sin embargo, desde una perspectiva funcional, ambos son protocolos utilizados por Samba.

La versión 1 del protocolo SMB no debería usarse, y en Samba está deshabilitado por defecto, debido a los ataques que hubo por el ransomware Wannacry. Estos ataques utilizaban una vulnerabilidad en servidores que no estaban parcheados.

15.5.1 Preparando el servidor

Antes de realizar la configuración del Dominio tenemos que realizar una serie de modificaciones para dejar el servidor preparado.

root@vega:~# systemctl stop systemd-resolved
root@vega:~# systemctl disable systemd-resolved

nameserver 127.0.0.1

127.0.0.1      localhost
192.168.1.200  dc.midominio.com dc

15.5.2 Configurar Samba como Controlador de Dominio

Para comenzar con la configuración de Samba como un controlador de dominios para sistemas Windows tendremos que parar el servidor Samba:

root@vega:~# smbcontrol all shutdown

Esto hace que los servicios de Samba (smbd y nmbd) se paren. Debido a que el fichero de configuración va a sufrir grandes cambios, y la configuración que tiene tras la instalación no es necesaria, se va a mover el fichero de configuración para guardarlo como backup:

root@vega:~# cd /etc/samba
root@vega:~# mv smb.conf smb.conf_backup

Al igual que hicimos con Windows Server a la hora de crear Active Directory, en Samba también vamos a necesitar de un DNS que esté gestionado por el propio controlador de dominio. En nuestro caso, como veremos más adelante, Samba levantará un DNS propio, pero tendremos que hacer que nuestro sistema GNU/Linux haga uso de él, tal como se explicará en el siguiente apartado.

Antes de eso, para realizar la configuración inicial del dominio, tenemos que ejecutar:

root@vega:~# samba-tool domain provision

Nos va a realizar una serie de preguntas, que tendremos que contestar:

• Realm: el nombre del Dominio que queremos crear. Ejemplo: linuxdc.com.

• Domain: Nombre de dominio NETBIOS. Debe ser una única palabra de máximo 15 caracteres. Por ejemplo linuxdc.

• Server Role: Es el tipo de rol que va a tener nuestro servidor. Puede ser uno de los siguientes:

  • dc: Domain Controller, es decir, controlador de dominio de Windows. Este es el modo que nos va a interesar en nuestro caso, ya que actuará como si se tratara de un Active Directory.

    En el fichero de configuración nos aparecerá como “active directory domain controller”

  • member: Miembro de un dominio. Nos permitiría que Samba sea un miembro de un dominio Windows.

  • standalone: Este es el modo por defecto una vez hemos instalado Samba, tal como se ha comentado previamente.

• DNS backend: Servidor backend de DNS. Al igual que Windows hacía uso de DNS, Samba cuando se convierte en controlador de dominio también. Existe la posibilidad de utilizar un servidor DNS propio (como Bind) pero en caso de usar “SAMBA_INTERNAL” Samba levantará un DNS propio.

• DNS forwarder IP address: El DNS al que se preguntará los DNS que desconocemos. Podemos poner el de Google, 8.8.8.8, o cualquier otro DNS público.

• Administrator password: Contraseña del administrador del Controlador de Dominio.

Una vez realizada la configuración inicial, antes de arrancar tenemos que instalar Winbind, que es necesario, y por si acaso lo paramos, para que después lo arranque Samba:

root@vega:~# systemctl stop winbind

Hay que recordar que ahora mismo tenemos el servicio de Samba parado, y lo único que hemos realizado ha sido la configuración inicial, por lo que el fichero de configuración /etc/samba/smb.conf ha sido modificado teniendo en cuenta las respuestas que hayamos dado previamente.

root@vega:~# samba -F -i -d1

root@vega:~# ss -puntal | grep smb

Netid  State   Recv-Q  Send-Q   Local Address:Port  Peer Address:Port  Process
tcp    LISTEN  0       50       0.0.0.0:139         0.0.0.0:*    users:(("smbd",pid=6041,fd=47))
tcp    LISTEN  0       50       0.0.0.0:445         0.0.0.0:*    users:(("smbd",pid=6041,fd=46))
tcp    LISTEN  0       50       [::]:139            [::]:*       users:(("smbd",pid=6041,fd=45))
tcp    LISTEN  0       50       [::]:445            [::]:*       users:(("smbd",pid=6041,fd=44))

root@vega:~# samba-tool

root@vega:~# samba-tool user create profesor1

root@vega:~# samba-tool user list
profesor1
Administrator
Guest
krbtgt

15.5.3 Meter Windows 10 en Samba Domain Controller

Ha llegado el momento de meter un equipo Windows en el Dominio que tenemos gestionado por nuestro servidor Samba. Los pasos a dar serán los mismos que cuando metemos el equipo en un Active Directory.

• Cambiar el nombre al equipo: Esto hará que después sea más fácil realizar la gestión de equipos y saber a quién pertenece el equipo o dónde se sitúa.

• Cambiar DNS del equipo para que haga uso de la IP del servidor Samba.

• Vamos a “Panel de Control > Sistema y Seguridad > Sistema”: Aquí le damos a “Cambiar configuración” dentro de la configuración de Dominio, y lo añadimos a nuestro Dominio creado previamente. Para añadirlo haremos uso del usuario Administrador que tenemos creado en el Controlador de Dominio Samba. Como pasaba al añadirlo a un Active Directory, el equipo tendrá que reiniciarse.

Una vez añadido el equipo, podremos loguearnos usando el usuario creado previamente.

15.6.1 Crear carpeta compartida

Para crear una carpeta compartida accesible por los usuarios creados en Samba, podemos modificar el fichero de configuración y añadir una sección que sea similar a la siguiente:

[sistemas]
    browseable = No
    comment = Carpeta Sistemas compartida
    path = /home/sistemas
    create mask = 0777
    directory mask = 0777
    read only = No
    valid users = profesor1

Esta sección cuenta con distintos parámetros que hay que entender:

• [sistemas]: es el nombre de la carpeta tal como accederemos desde Windows.

• browseable: indica si la carpeta puede ser “buscada” accediendo al servidor o si debemos conocer cómo se llama la carpeta para acceder a ella directamente.

• comment: comentario sobre la carpeta compartida.

• path: ruta en el servidor GNU/Linux donde realmente se encuentra la carpeta compartida.

• create mask: cuando se crea un fichero en la carpeta compartida, los permisos que tendrá el fichero en GNU/Linux.

• directory mask: cuando se crea un directorio en la carpeta compartida, los permisos que tendrá el fichero en GNU/Linux.

• read only: si queremos que la carpeta compartida sea de modo sólo lectura.

• valid users: usuarios que podrán acceder a la carpeta compartida. Estos usuarios deberán haber sido creados previamente en Samba (mirar apartado de creación de usuarios).

  • Si queremos que puedan conectarse varios usuarios, deberemos poner el listado separado por espacios.

  • Si queremos que puedan conectarse a esta carpeta todos los usuarios de un grupo, deberemos poner @nombre_grupo en esta variable.

16.1.1 Rsync para sincronizar de manera remota

Tal como sabemos, nunca deberíamos realizar copias de seguridad de manera local en el mismo disco duro, ni tenerlas en el mismo equipo, por lo que es necesario poder realizar copias de seguridad desde otros servidores o a otros servidores.

Imaginemos que queremos copiar los datos de una carpeta compartida /home/sistemas al servidor remoto 10.40.30.200, y dejar una copia en /home/backups:

ruben@vega:~$ rsync -av /home/sistemas  root@10.40.30.200:/home/backups

Con este comando realizaremos la sincronización al servidor remoto haciendo uso de SSH y conectándonos con el usuario root remoto. Explicación de los distintos apartados del comando:

• rsync es el programa que usamos para realizar la sincronización.

• -av son los parámetros que realizan la sincronización en moodo archivos y en modo “verbose” (nos indica qué está sincronizando).

• /home/sistemas es el directorio con los datos de origen que vamos a sincronizar

• root es el usuario con el que nos vamos a conectar al servidor remoto.

• @10.40.30.200: es el servidor al que nos vamos a conectar por SSH para realizar en él la copia. ¡OJO! Es importante esa “@” y los “:” al final.

• /home/backups es el lugar donde dejaremos una copia de los datos a sincronizar.

Tal como se ha comentado, rsync hará uso de SSH para realizar la conexión remota, por lo que los datos se enviarán de manera segura y cifrada.

16.1.2 Obtener datos remotos

Si queremos realizar la sincronización en el orden inverso, obtener los datos estando en el servidor de backup y traernos los datos de un servidor remoto, el comando sería:

root@backups:~# rsync -av 10.40.30.5:/home/sistemas  /home/backups

En este caso, estando en el servidor de backups, vamos a traernos los datos del servidor 10.40.30.5. En este caso, antes de la IP del servidor no hemos puesto usuario, por lo que se realizará la conexión con el mismo usuario que somos actualmente, en este caso root.

16.1.3 Opciones extra

Hasta ahora hemos visto las opciones más básicas para sincronizar directorios (tanto locales como remotos), pero rsync cuenta con muchas opciones extra que es interesante conocer:

• -z o --compress sirve para comprimir los datos antes de realizar el envío o recepción de los datos. Sólo es útil si vamos a realizar la sincronización de manera remota.

• --progress sirve para ver el progreso de cómo va la transferencia de los ficheros

• --delete sirve para borrar en el destino los ficheros que no existen en el origen.

• --exclude “*txt” excluye los ficheros que termina con la extensión “txt” al hacer la sincronización.

18.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.

18.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

19.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:

19.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:

19.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.

19.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.

19.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.

19.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.

19.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:

19.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.

20.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:

20.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.

20.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.

20.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.

21.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.

21.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.

21.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.

21.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).

21.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.

21.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.

21.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

• ...

21.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.

21.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.

21.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.

21.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.

21.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.

21.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, ...

21.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.

21.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.

21.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.

22.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.

22.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.

22.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.

22.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.

22.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.

22.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.

23.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:

24.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.

24.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.

24.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.

24.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.

24.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.