En este post veremos cómo crear un almacén de datos ZFS en Proxmox Backup Server (PBS) para los repositorios de las copias de seguridad inmutables, esta inmutabilidad será de forma manual.

La topología utilizada sería la siguiente:

• Antes de empezar, vemos que en nuestro Proxmox Backup Server, le hemos añadido tres discos de 200GB dónde vamos a montar un RAIDZ (RAID 5) con ZFS para crear el repositorio de nuestras copias de seguridad inmutables:

• Desde la consola web de nuestro PBS, accedemos a Almacenamiento/Discos, y podemos ver, que ya tenemos disponibles los tres discos de 200 GB que hemos añadido:

• Clicamos sobre Almacenamiento/Discos > ZFS:

• Creamos el pool ZFS:

• Le indicamos los tres discos que vamos a utilizar, le asignamos un nombre y marcamos el check para que automáticamente nos agregue el Datastore al almacenamiento de nuestro PBS, como nivel de RAID en este caso le indicamos RAIDZ que equivale a un RAID 5, Crear:

• Como podemos ver, aquí se ha creado el pool de ZFS:

• Y aquí vemos, el almacén de datos creado:

• Estas son las opciones de RAID que tenemos en ZFS con Proxmox:
• Single Disk (Disco Único), es la configuración más básica, no hay redundancia. Cómo funciona: Los datos se escriben en un solo disco. Seguridad: Nula. Si el disco falla, pierdes todos los datos. Uso ideal: Pruebas, entornos de desarrollo no críticos o si tienes una estrategia de backup externa extremadamente sólida.
• Mirror (RAID 1), el clásico «espejo», requiere al menos 2 discos. Cómo funciona: Todo lo que se escribe en el Disco A se replica exactamente en el Disco B. Seguridad: Alta. Puede fallar un disco y el sistema seguirá funcionando. Rendimiento: Muy bueno en lectura (lee de ambos), pero la capacidad total es solo la de un disco.
• RAID 10 (Striped Mirrors), es una combinación de Mirroring y Striping, requiere al menos 4 discos (siempre en pares). Cómo funciona: Crea parejas de espejos (mirrors) y luego reparte los datos entre esas parejas. Seguridad: Puede fallar un disco por cada pareja de espejos. Es el más resistente y el que mejor se recupera . Rendimiento: Es el rey del rendimiento en ZFS, especialmente para bases de datos y muchas máquinas virtuales.
• RAIDZ (Equivalente a RAID 5), requiere al menos 3 discos. Cómo funciona: Utiliza un disco para «paridad», los datos se distribuyen entre todos los discos. Seguridad: Soporta el fallo de 1 disco, si falla un segundo disco antes de reemplazar el primero, se pierde todo. Capacidad: Pierdes el espacio equivalente a un disco. Nota: No se recomienda con discos mecánicos de gran capacidad (8TB+) debido al largo tiempo de reconstrucción.
• RAIDZ2 (Equivalente a RAID 6), requiere al menos 4 discos. Cómo funciona: Doble paridad distribuida. Seguridad: Soporta el fallo de 2 discos simultáneamente. Es el estándar de oro para almacenamiento masivo de datos. Capacidad: Pierdes el espacio equivalente a dos discos.
• RAIDZ3, requiere al menos 5 discos. Cómo funciona: Triple paridad distribuida. Seguridad: Soporta el fallo de hasta 3 discos. Es extremadamente seguro. Uso ideal: Solo para servidores con muchísimos discos (ej. 10 o 12 discos por vdev) donde la probabilidad de fallos múltiples es mayor.
• Una vez que hemos creado el repositorio ZFS en Proxmox Backup Server, sobre nuestro cluster de Proxmox VE, accedemos a Centro de datos > Almacenamiento > Agregar > Proxmox Backup Server:

• Sobre General, le indicamos el ID, Servidor y credenciales del PBS, los nodos a los que le vamos a presentar el datastore para los backups, Activar, como contenido de backup, le asignamos un nombre al datastore y le indicamos la Huella digital de nuestro PBS:

• La Huella digital del PBS, la copiamos del servidor PBS:

• Sobre Retención de respaldos, lo dejamos tal cuál nos lo muestra, ya que esto lo configuraremos en los propios trabajos de backups:

• Sobre Cifrado, le indicamos que autogenere una llave de cifrado para el cliente, Agregar:

• Descargamos la llave de cifrado y la guardamos en un lugar seguro, Cerrar:

• Y aquí tenemos ya creado y configurado nuestro datastore ZFS de Proxmox Backup Server que utilizaremos como repositorio de nuestros backups inmutables:

• Una vez creado y configurado el repositorio ZFS, vamos a crearnos una tarea de copia de seguridad inmutable, para ello, sobre nuestro cluster de Proxmox VE, accedemos a Centro de datos > Respaldo > Agregar:

• Sobre General, le indicamos el nodo (en nuestro caso, como es un clúster, Todo), el almacenamiento donde vamos a guardar los backups (Proxmox Backup Server), la programación, Compresión, Modo, le agregamos un comentario de descripción del backup y seleccionamos las máquinas a respaldar:

• Sobre Notificaciones, le podemos indicar la cuenta de correo, a la que queremos que nos lleguen los avisos de los respaldos:

• Sobre Retención, le vamos a indicar que nos mantenga los últimos 7 respaldos, a partir del séptimo irá sobrescribiendo los más antiguos, Crear:

• Aquí vemos la tarea creada:

• Ahora para probar la tarea, la vamos a lanzar de forma manual, Ejecutar ahora:

• Aquí vemos que el respaldo comienza a realizarse:

• Una vez finalizado, accedemos a nuestro Proxmox Backup Server > Almacén de datos > dts01zfspbs > Contenido, y podemos ver el contenido de nuestras copias de seguridad:

• Para hacer este backup inmutable, pulsamos sobre el símbolo del escudo GRIS que nos aparece en nuestro backup:

• Y marcamos el check Protegido, Aceptar:

• Como podemos ver, el escudo cambia a color VERDE y nos aparece el backup como protegido:

• Si intentamos eliminar su contenido, nos va a dar este mensaje de error:

• Esto pasa cuando protegemos un backup:
• El servidor le pone un atributo de «SÓLO LECTURA» a nivel de kernel de Linux.
• Incluso si un virus entra con permisos de administrador e intenta borrar la carpeta del backup, el sistema de archivos ZFS rechazará la orden porque el archivo tiene el bit de inmutabilidad activo.
• La inmutabilidad en PBS significa que el software le pone un candado digital (fattr) a los archivos en el pool de ZFS, mientras ese candado esté puesto, ni el propio Proxmox puede borrar los datos para dejar espacio a backups nuevos.
• Esta inmutabilidad que hemos mostrado es MANUAL, es decir, que por cada punto de retención que se vaya creando tendremos que habilitar de manera manual el candado.
• Esto es lo que pasaría:
• Día 1 al 7, realizamos los backups y les ponemos el candado, quedando protegidos, tenemos 7 puntos de recuperación inmutables.
• Día 8, se realiza el octavo backup y como los 7 anteriores tienen el candado activado y están protegidos, el sistema de limpieza (Prune) no puede borrar el día 1.
• Resultado, ahora tenemos 8 backups ocupando espacio en nuestro datastore ZFS.
• Tendríamos que entrar una vez por semana, quitarle el candado al más viejo (Día 1) y ponérselo al más nuevo (Día 8), esto permite que el proceso de Garbage Collection de ZFS, libere los bloques de datos del Día 1.
• Para restaurar una máquina completa sobrescribiendo la actual, accedemos a la propia máquina > Respaldo > Almacenamiento > Seleccionamos el backup > Restaurar:

• Si queremos restaurar archivos, accedemos a la propia máquina > Respaldo > Almacenamiento > Seleccionamos el backup > Restauración de archivo:

• Si quisiera restaurar la máquina completa sin sobrescribir la original, dts01zfspbs > Respaldos > Seleccionamos el backup > Restaurar:

• Le indico el datastore donde la quiero restaurar, y el nuevo ID de máquina virtual, Restaurar:

Saludos y espero que os sea de ayuda

La entrada Crear almacén de datos ZFS en Proxmox Backup Server para los repositorios de copias de seguridad inmutables se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como realizar una actualización in-place de Windows Server 2022 a Windows Server 2025.

Una de las últimas novedades que nos presenta Microsoft, es que ahora podemos realizar actualizaciones in-place de Windows Server 2012 R2, 2016, 2019 y 2022 a Windows Server 2025 como una actualización de características (Feature Update) desde Windows Update, también desde una ISO podemos actualizar desde estos sistemas operativos más antiguos a Windows Server 2025.

Algunas recomendaciones antes de actualizar son:

• El servidor debe contar con las últimas actualizaciones acumulativas mensuales instaladas, especialmente parches posteriores a marzo de 2026.
• Al menos 32 GB de espacio libre en el disco de sistema.
• Realizar un backup de la máquina.
• Realizar un snapshot de la máquina.
• Los controladores de dominio y clústeres de Microsoft se recomienda no usar este método y hacer una actualización planificada como las hemos realizado siempre, en este mismo blog podréis encontrar información al respecto.
• Tener licencia de Windows Server 2025

En este link de Microsoft tenéis toda la información al completo.

• Al tratarse de un cambio crítico de plataforma, Microsoft la ofrece como una actualización opcional, pero el aviso en la configuración de Windows Update no nos va a aparecer, hasta que no hagamos este cambio en el registro de Windows.
• Abrimos el Editor del Registro con regedit:

• Navegamos hasta la ruta, HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate:

• Si no existe, creamos una clave (carpeta) llamada, AllowWindowsServerFeatureUpdate:

• Dentro de ella, creamos un valor DWORD (32 bits) con el nombre exacto, AllowWindowsServerFeatureUpdate y le asignamos el valor 1:

• Reiniciamos el equipo para que los cambios se hagan efectivos:

• Ahora vamos a Configuración > Actualización y seguridad > Windows Update
• Veremos un banner, ofreciendo la Actualización de características a Windows Server 2025
• Hacemos clic en Descargar e instalar:

• Se nos abrirá esta ventana de términos y condiciones donde se mostrará información importante sobre licenciamiento, privacidad y compatibilidad de aplicaciones,haz clic en Aceptar e instalar:

• El sistema operativo comienza a descargar los paquetes en segundo plano y preparará la instalación, este proceso mantiene intactos nuestros roles, características, configuraciones y datos seleccionando internamente la opción equivalente a Mantener ficheros, configuraciones y aplicaciones, “Keep files, settings, and apps”:

• Aquí vemos nuestro sistema migrado a Windows Server 2025:

• Una vez que el sistema se ha migrado a Windows Server 2025, debemos de:
• Verificar los servicios que teníamos operativos que sigan funcionando correctamente.
• Activar la licencia de Windows Server 2025.
• Actualizar Windows Server 2025 con los últimos parches de seguridad
• Pasado un tiempo y confirmado que el entorno es 100% operativo, podemos usar el Liberador de espacio en disco, para eliminar la carpeta old y recuperar el espacio en disco utilizado por el sistema operativo anterior.

Saludos y espero que os sea de ayuda

La entrada Actualización In-Place a Windows Server 2025 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam ONE 13.0.1.6168 a la nueva versión 13.0.2.6723 liberada por Veeam hace algunos días.

• Como podemos ver aquí, tenemos descargada la v13.0.2.6723 de Veeam ONE:

• Vemos que la versión que tenemos instalada es la 13.0.1.6168:

• Nos montamos la imagen ISO, y ejecutamos el setup para proceder con la instalación del upgrade a la 0.2.6723:

• Ejecutamos el Upgrade:

• Seleccionamos Upgrade Veeam ONE:

• Aceptamos el EULA:

• Nos indica que ha detectado una versión previa de Veeam ONE, y que va a actualizar a ésta última, clic sobre Next para proceder con el upgrade:

• Debemos especificar una cuenta para el servicio de Veeam ONE, esta cuenta la creamos y la configuramos en la primera instalación que hicimos de Veeam ONE, por lo que, en este caso, sólo debemos de introducir el password que configuramos en la instalación original:

• Comienza a verificar el sistema para identificar cualquier tipo de problema:

• Damos a Upgrade para proceder con la actualización:

• Comienza con la actualización:

• Como podemos ver la actualización a v13.0.2.6723, ha finalizado correctamente:

• Una vez finalizada la instalación, podemos ver, que ya tenemos instalada la última versión de Veeam ONE v13.0.2.6723:

Saludos y espero que os resulte de ayuda

La entrada Actualizar Veeam ONE v13.0.1.6168 a la nueva versión 13.0.2.6723 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam Backup & Replication v13.0.1.2067 a la nueva versión 13.0.2.29, en este link podemos ver las nuevas características de esta versión, y en este link podemos ver la lista de vulnerabilidades que corrige.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v13.0.1.2067:

• Desde aquí nos descargamos la ISO, versión 13.0.2.29 para sistemas Microsoft Windows:

• Aquí tenemos ya, la nueva ISO v13.0.2.29 para Microsoft Windows descargada:

• Montamos la ISO y ejecutamos el setup:

• Comienza la actualización, Upgrade:

• Seleccionamos Upgrade Veeam Backup & Replication:

• Aceptamos el EULA:

• Marcamos los checks para actualizar la licencia y recibir soporte, Next:

• Comienza a chequear las configuraciones y si nos falta algún componente, lo irá instalando:

• Nos indica los componentes que se han instalado, y que tres de ellos, requieren reinicio, Reboot:

• Una vez reiniciado, volvemos a lanzar el setup, hasta llegar al mismo punto donde nos quedamos.
• Nos indica algunos avisos de compatibilidades, pero nada importante que nos impida actualizar:

• Nos indica todos los componentes que van a ser actualizados, Upgrade:

• Comienza con la actualización, aquí debemos de tener un poco de paciencia ya que el proceso es bastante lento:

• Como podemos ver, la actualización a v13.0.2.29, ha finalizado correctamente:

Saludos y espero que os resulte de ayuda

La entrada Actualizar Veeam Backup & Replication v13.0.1.2067 a v13.0.2.29 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar Onlyoffice Document Server con Docker, este servidor de documentos de la comunidad está diseñado para facilitar la ejecución de OnlyOffice en una instancia de Nextcloud sin necesidad de configurar un servidor de documentos externo, por lo tanto, lo vamos a integrar con el servidor de nextcloud que desplegamos en el post anterior.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 26.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para onlyofficeds en nuestro DNS interno, apuntando a www y este a su vez apunta a la máquina docker dónde tenemos instalado un Nginx Proxy Manager para los accesos externos:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de Onlyoffice:
• sudo mkdir -p /opt/docker/nextcloud/onlyofficeds/data
• sudo mkdir -p /opt/docker/nextcloud/onlyofficeds/logs
• sudo chmod -R 755 /opt/docker/nextcloud/onlyofficeds

• Ahora vamos a crearnos el fichero .env para no dejar credenciales en texto plano en el fichero docker-compose.yaml que crearemos posteriormente, utilizando para ello variables, para ello, nos situamos en cd /opt/docker/nextcloud/onlyofficeds, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• JWT_SECRET=clave_muy_segura
• JWT_HEADER=Authorization

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

onlyoffice-ds:

image: onlyoffice/documentserver:9.4.0

container_name: onlyoffice-ds

restart: unless-stopped

#   ports:

#     – «8081:80»

environment:

– JWT_ENABLED=true

– JWT_SECRET=${JWT_SECRET}

– JWT_HEADER=${JWT_HEADER}

volumes:

– /opt/docker/nextcloud/onlyofficeds/data:/var/lib/onlyoffice

– /opt/docker/nextcloud/onlyofficeds/logs:/var/log/onlyoffice

networks:

– npmdmz-net

networks:

npmdmz-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos el archivo .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/nextcloud/onlyofficeds/.env

• Ahora, iniciamos el contenedor de Onlyofficeds, cd /opt/docker/nextcloud/onlyofficeds/, sudo docker compose up -d:

• Aquí vemos el contenedor levantado, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para onlyofficeds.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: onlyofficeds.ragasyssistemas.com
• Esquema: http
• Nombre de Host/IP de reenvío: onlyoffice-ds
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos, ya tenemos acceso a nuestro Onlyoffice Document Server a través de nuestro proxy inverso con Nginx Proxy Manager:

• Para que Onlyoffice nos funcione y se integre con nuestro servidor de Nextcloud, debemos de agregar esta línea al final del fichero config.php, sudo nano /opt/docker/nextcloud/nextcloudapp/html/config/config.php, ‘allow_local_remote_servers’ => true, :

• Con sudo docker restart nextcloud-app reiniciamos la aplicación de Nextcloud:

• Ahora accedemos a nuestro Nextcloud y vamos a instalar el conector de Onlyoffice Document Server, para ello, accedemos a Aplicaciones:

• Sobre Archivos, buscamos Onlyoffice y damos a Descargar y activar:

• Una vez descargada y activada, accedemos a Apps activas, y vemos que ya la tenemos operativa:

• Ahora accedemos a Configuración de administración:

• Sobre ONLYOFFICE >Ajustes de servidor, configuramos la Dirección de ONLYOFFICE y la Clave Secreta que configuramos en nuestro .env, Guardar:

• Una vez guardada, tendremos los distintos ajustes para configurar, como las extensiones de ficheros que podremos editar con Onlyoffice:

• Ahora vamos a realizar una prueba, nos vamos a abrir un documento de Word y otro de Excel para verificar que podemos editar documentos online a través de Nextcloud:

• Edición fichero Word online:

• Edición fichero Excel online:

Saludos y espero que os sea de ayuda

La entrada Desplegar Onlyoffice Document Server con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar nextcloud con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de Nextcloud con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

Nextcloud es un espacio de trabajo digital moderno que integra herramientas clave de productividad y colaboración en una plataforma unificada y modular, fácil de usar y gestionar.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 26.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para nextcloud en nuestra zona externa, ya que este servicio lo vamos a publicar al exterior, va a apuntar a www y este a su vez apunta a la máquina docker dónde tenemos instalado un Nginx Proxy Manager para los accesos externos:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de MariaDB y Nextcloud:
• sudo mkdir -p /opt/docker/nextcloud/nextclouddb/data
• sudo mkdir -p /opt/docker/nextcloud/nextclouddb/config
• sudo mkdir -p /opt/docker/nextcloud/nextcloudapp/html
• sudo chmod -R 755 /opt/docker/nextcloud/nextclouddb
• sudo chmod -R 755 /opt/docker/nextcloud/nextcloudapp

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.2.0/24 –gateway 172.25.2.1 -d bridge nextcloud-net, con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect nextcloud-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en cd /opt/docker/nextcloud/nextclouddb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=clave_muy_segura_root_db
• MYSQL_DATABASE=nextclouddb
• MYSQL_USER=nextclouduser
• MYSQL_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

nextcloud-db:

image: mariadb:12.2

container_name: nextcloud-db

restart: unless-stopped

env_file: .env

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/nextcloud/nextclouddb/data:/var/lib/mysql

– /opt/docker/nextcloud/nextclouddb/config:/etc/mysql/conf.d:ro

networks:

– nextcloud-net

networks:

nextcloud-net:

name: nextcloud-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de nextcloud app, para ello, nos situamos en cd /opt/docker/nextcloud/nextcloudapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

MYSQL_USER=nextclouduser

MYSQL_PASSWORD=clave_muy_segura_db

MYSQL_DATABASE=nextclouddb

NEXTCLOUD_ADMIN_USER=admnextcloud

NEXTCLOUD_ADMIN_PASSWORD=clave_muy_segura_useradmin_nextcloud

NEXTCLOUD_TRUSTED_DOMAINS=nextcloud.ragasyssistemas.com

• Nos creamos el fichero docker-compose.yaml para el contenedor de wordpress-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

nextcloud-app:

image: nextcloud:33-apache

container_name: nextcloud-app

restart: unless-stopped

#   ports:

#     – «8080:80»

env_file: .env

environment:

– MYSQL_HOST=nextcloud-db:3306

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– NEXTCLOUD_ADMIN_USER=${NEXTCLOUD_ADMIN_USER}

– NEXTCLOUD_ADMIN_PASSWORD=${NEXTCLOUD_ADMIN_PASSWORD}

– NEXTCLOUD_TRUSTED_DOMAINS=${NEXTCLOUD_TRUSTED_DOMAINS}

– TRUSTED_PROXIES=172.25.1.0/24 # Subred de Nginx Proxy Manager External

– OVERWRITEPROTOCOL=https

volumes:

– /opt/docker/nextcloud/nextcloudapp/html:/var/www/html

networks:

– nextcloud-net    # Para comunicar con la DB

– npmdmz-net       # Para comunicar con Nginx Proxy Manager External

networks:

nextcloud-net:

external: true

npmdmz-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/nextcloud/nextclouddb/.env
• sudo chmod 600 /opt/docker/nextlcloud/nextcloudapp/.env

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/nextcloud/nextclouddb/.env
• sudo chmod 600 /opt/docker/nextlcloud/nextcloudapp/.env

• Iniciamos el contenedor de nextcloud-app, cd /opt/docker/nextcloud/nextcloudapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para wordpress.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: nextcloud.ragasyssistemas.com
• Esquema: http
• Nombre de Host/IP de reenvío: nextcloud-app
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos, ya tenemos acceso a nuestro nextcloud a través de nuestro proxy inverso con Nginx Proxy Manager:

Saludos y espero que os resulte de ayuda

La entrada Desplegar Nextcloud con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar Drupal con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de PostgreSQL para la base de datos que vamos a utilizar y el otro el propio de Drupal con la aplicación, este servicio irá desplegado, sobre otra máquina distinta dónde está desplegado nuestro docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para drupal apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de PostgreSQL y Drupal:
• sudo mkdir -p /opt/docker/drupal/drupaldb/data
• sudo mkdir -p /opt/docker/drupal/drupalapp/modules
• sudo mkdir -p /opt/docker/drupal/drupalapp/profiles
• sudo mkdir -p /opt/docker/drupal/drupalapp/themes
• sudo mkdir -p /opt/docker/drupal/drupalapp/sites
• sudo chmod -R 755 /opt/docker/drupal/drupaldb
• sudo chmod -R 755 /opt/docker/drupal/drupalapp
• sudo chown 33:33 /opt/docker/drupal/drupalapp/sites
• sudo chmod 775 /opt/docker/drupal/drupalapp/sites

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.2.0/24 –gateway 172.25.2.1 -d bridge drupal-net con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect drupal-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de PostgreSQL, para ello, nos situamos en cd /opt/docker/drupal/drupaldb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• POSTGRES_DB=drupaldb
• POSTGRES_USER=drupaluser
• POSTGRES_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de PostgraSQL en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

drupal-db:

image: postgres:16.6

container_name: drupal-db

restart: unless-stopped

env_file: .env

volumes:

– /opt/docker/drupal/drupaldb/data:/var/lib/postgresql/data

networks:

– drupal-net

networks:

drupal-net:

name: drupal-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de drupal app, para ello, nos situamos en cd /opt/docker/drupal/drupalapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

DRUPAL_DB_HOST=drupal-db

DRUPAL_DB_PORT=5432

DRUPAL_DB_NAME=drupaldb

DRUPAL_DB_USER=drupaluser

DRUPAL_DB_PASSWORD=clave_muy_segura_db

DRUPAL_DB_DRIVER=pgsql

• Nos creamos el fichero docker-compose.yaml para el contenedor de drupal-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

drupal-app:

image: drupal:10-apache

container_name: drupal-app

restart: unless-stopped

ports:

– 8081:80

entrypoint:

– /bin/sh

– -c

– |

# 1. Aseguramos que existan las carpetas base en el volumen

echo «Creando estructura de directorios…»

mkdir -p /var/www/html/sites/default/files/translations

# 2. Si NO existe default.settings.php en el volumen, lo traemos del backup interno de Drupal

# Nota: Las imágenes oficiales de Drupal guardan una copia en /opt/drupal/web/sites…

# pero para asegurar, lo creamos si no existe.

if [ ! -f /var/www/html/sites/default/default.settings.php ]; then

echo «Restaurando default.settings.php…»

# Intentamos copiarlo de la ubicación de la imagen si está disponible

cp /opt/drupal/web/sites/default/default.settings.php /var/www/html/sites/default/default.settings.php 2>/dev/null || touch /var/www/html/sites/default/default.settings.php

fi

# 3. Si no hay settings.php, lo creamos

if [ ! -f /var/www/html/sites/default/settings.php ]; then

echo «Creando settings.php…»

cp /var/www/html/sites/default/default.settings.php /var/www/html/sites/default/settings.php

fi

# 4. Permisos correctos para el usuario 33 (www-data)

echo «Aplicando permisos…»

chown -R 33:33 /var/www/html/sites

chmod -R 775 /var/www/html/sites/default/files

# 5. Arrancar Apache

exec apache2-foreground

env_file: .env

environment:

– DRUPAL_DATABASE_HOST=${DRUPAL_DB_HOST}

– DRUPAL_DATABASE_NAME=${DRUPAL_DB_NAME}

– DRUPAL_DATABASE_USER=${DRUPAL_DB_USER}

– DRUPAL_DATABASE_PASSWORD=${DRUPAL_DB_PASSWORD}

– DRUPAL_DATABASE_DRIVER=${DRUPAL_DB_DRIVER}

volumes:

– /opt/docker/drupal/drupalapp/modules:/var/www/html/modules

– /opt/docker/drupal/drupalapp/profiles:/var/www/html/profiles

– /opt/docker/drupal/drupalapp/themes:/var/www/html/themes

– /opt/docker/drupal/drupalapp/sites:/var/www/html/sites

networks:

– drupal-net

networks:

drupal-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/drupal/druapldb/.env
• sudo chmod 600 /opt/docker/drupal/drupalapp/.env

• Ahora, iniciamos primero el contenedor de PostgreSQL, cd /opt/docker/drupal/drupaldb/, sudo docker compose up -d:

• Iniciamos el contenedor de drupal-app, cd /opt/docker/drupal/drupalapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para Drupal.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: 192.168.14.17 IP máquina Docker02
• Puerto: 8081
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro drupal a través de nuestro proxy inverso con Nginx Proxy Manager, ahora nos va a pedir lo típico tras el primer acceso.
• Escogemos el idioma:

• Elegimos el perfil:

• Configuramos el acceso a la base de datos:

• Comienza a instalar Drupal:

• Configuración de traducciones:

• Configuramos nuestro sitio de drupal:

• Termina las traducciones:

• Iniciamos sesión en nuestro portal de drupal:

• Ya estamos listos para empezar a publicar:

Saludos y espero que os sea de ayuda

La entrada Desplegar Drupal con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar wordpress con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de WordPress con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para wordpress apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de MariaDB y WordPress:
• sudo mkdir -p /opt/docker/wprgs/wprgsdb/data
• sudo mkdir -p /opt/docker/wprgs/wprgsdb/config
• sudo mkdir -p /opt/docker/wprgs/wprgsapp/config
• sudo chmod -R 755 /opt/docker/wprgs/wprgsdb
• sudo chmod -R 755 /opt/docker/wprgs/wprgsapp

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.3.0/24 –gateway 172.25.3.1 -d bridge wprgs-net, con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect wprgs-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en cd /opt/docker/wprgs/wprgsdb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=clave_muy_segura_root_db
• MYSQL_DATABASE=wprgsdb
• MYSQL_USER=wprgsuser
• MYSQL_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

wprgs-db:

image: mariadb:12.2

container_name: wprgs-db

restart: unless-stopped

env_file: .env

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/wprgs/wprgsdb/data:/var/lib/mysql

– /opt/docker/wprgs/wprgsdb/config:/etc/mysql/conf.d:ro

networks:

– wprgs-net

networks:

wprgs-net:

name: wprgs-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de wordpress app, para ello, nos situamos en cd /opt/docker/wprgs/wprgsapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

WORDPRESS_DB_USER=wprgsuser

WORDPRESS_DB_PASS=clave_muy_segura_db

WORDPRESS_DB_NAME=wprgsdb

• Nos creamos el fichero docker-compose.yaml para el contenedor de wordpress-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

wprgs-app:

image: wordpress:6.9.4-php8.5-apache

container_name: wprgs-app

restart: unless-stopped

ports:

– «8081:80»

env_file: .env

environment:

– WORDPRESS_DB_HOST=wprgs-db:3306

– WORDPRESS_DB_USER=${WORDPRESS_DB_USER}

– WORDPRESS_DB_PASSWORD=${WORDPRESS_DB_PASS}

– WORDPRESS_DB_NAME=${WORDPRESS_DB_NAME}

– WORDPRESS_CONFIG_EXTRA=define(‘WP_HOME’,’https://wprgs.ragasys.net’); define(‘WP_SITEURL’,’https://wprgs.ragasys.net’); if (isset($$_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $$_SERVER[‘HTTP_X_FORWARDED_PROTO’] === ‘https’) { $$_SERVER[‘HTTPS’] = ‘on’; }

volumes:

– /opt/docker/wprgs/wprgsapp/config:/var/www/html

networks:

– wprgs-net  # Para comunicar con la DB

– npm-net    # Para comunicar con Nginx Proxy Manager

networks:

wprgs-net:

external: true

npm-net:

external: true

• Aquí debemos tener en cuenta, que la línea de los puertos 8081:80, la hemos dejado solo para verificar que el servicio se levanta en esos puertos por HTTP, una vez que configuremos nuestro Nginx Proxy Manager para el acceso por HTTPS con los certificados de Let’s Encrypt esta línea la podemos quitar o comentar, y con respecto a la variable WORDPRESS_CONFIG_EXTRA, es para indicarle al wordpress que está detrás de un proxy, también podemos ver que se conecta con la red de Nginx Proxy Manager npm-net, ya qu el acceso será a través de nuesro proxy inverso.
• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/wprgs/wprgsdb/.env
• sudo chmod 600 /opt/docker/wprgs/wprgapp/.env

• Ahora, iniciamos primero el contenedor de MariaDB, cd /opt/docker/wprgs/wprgsdb/, sudo docker compose up -d:

• Iniciamos el contenedor de wprgs-app, cd /opt/docker/wprgs/wprgsapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para wordpress.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: wprgs-app
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro wordpress a través de nuestro proxy inverso con Nginx Proxy Manager, ahora nos va a pedir lo típico tras el primer acceso:

• Introducimos las credenciales y ya estamos dentro de nuestro wordpress, listo para empezar a publicar:

Saludos y espero que os resulte de ayuda

La entrada Desplegar WordPress con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver de forma muy resumida las redes en docker, redes que se crean por defecto, redes que vamos a crear nosotros de manera simple y otras que crearemos algo más complejas y personalizadas, inspección de redes, eliminación de redes, etc…

• Cuando instalamos docker en nuestra máquina si le hacemos un ip a vemos que nos ha creado la interface de red docker0:

• Si hacemos un sudo docker network ls podemos listar todas las redes que docker nos crea por defecto:

• Si le hacemos un sudo docker network inspect bridge, podemos ver, que la red por defecto bridge tiene el rango de red 172.17.0.0/16 y gateway 172.17.0.1, si añadimos contenedores docker en esta red, les va a ir asignado las IPs que vaya teniendo libres de menor a mayor:

• Con sudodocker network create test1-net, nos vamos a crear una red de manera simple y sencilla:

• Aquí vemos la red creada:

• Con sudo docker network inspect test1-net, podemos ver, la configuración de esta red, y vemos que le asigna la red correlativa a la red por defecto de bridge, red 172.18.0.0/16 y gateway 172.18.0.1:

• Ahora vamos a crear otra red indicándole el rango que va a utilizar, el gateway, el driver (bridge) y el nombre de la red, para ello, ejecutamos sudo docker network create —subnet 10.10.10.0/24 –gateway 10.10.10.1 -d bridge npm-net:

• Aquí vemos la red creada:

• Con sudo docker network inspect npm-net, podemos ver, la configuración de esta red, y vemos que le asigna todo lo que le hemos indicado en el comando:

• Ahora, tenemos este docker-compose.yaml, para desplegar un contenedor Nginx Proxy Manager, y vamos a utilizar la red npm-net que hemos creado de manera personalizada con los parámetros que nos han interesado:

• Con sudo docker compose up -d levantamos el contenedor de Nginx Proxy Manager y con sudo docker ps -a vemos que ya lo tenemos levantado:

• Ahora si volvemos a ejecutar sudo docker network inspect npm-net, podemos ver, que el contenedor de Nginx Proxy Manager está utilizando la red personalizada que hemos creado anteriormente:

• Aquí tenemos nuestra aplicación levantada:

Saludos y espero que os sea de ayuda

La entrada Redes en Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam Backup & Replication v13.0.1.1071 a la nueva versión 13.0.1.2067, en este link podemos ver las nuevas características de esta versión, y en este link podemos ver la lista de vulnerabilidades que corrige.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v13.0.1.1071:

• Desde aquí nos descargamos la ISO, versión 13.0.1.2067 para sistemas Microsoft Windows:

• Aquí tenemos ya, la nueva ISO v13.0.1.2067 para Microsoft Windows descargada:

• Montamos la ISO y copiamos el ejecutable de la actualización patch a nuestra máquina de Veeam:

• Una vez copiado, lo ejecutamos y empezamos con el upgrade:

• Comienza la instalación del parche, Next:

• Comienza a comprobar compatibilidades:

• La instalación nos indica que ya está todo preparado, Install:

• Aquí vemos que la instalación del upgrade, está en curso:

• Como podemos ver, la actualización a v13.0.1.2067, ha finalizado correctamente:

Saludos y espero que os sea de ayuda

La entrada Actualizar Veeam Backup & Replication v13.0.1.1071 a v13.0.1.2067 se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo actualizar un host ESXi versión VMware vSphere 8.0 Update 3h a la versión 8.0 Update 3i a través de ESXCLI, en este link os dejo toda la información.

• Como podemos ver, nuestros hosts ESXi está en la versión 8.0.3 build 25067014:

• Para empezar nos descargamos de la web de Broadcom WMware el patch para la instalación offline a través de la ESXCLI de ESXi 8.0 Update 3i build 25205845:

• Cargamos este archivo en un datastore de nuestro vCenter:

• Ponemos el host ESXi que queremos actualizar en modo mantenimiento:

• Accedemos por SSH al host ESXi que queremos actualizar:

• Ejecutamos el siguiente comando para listar los perfiles disponibles del parche descargado, esxcli software sources profile list -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-depot.zip:

• Para realizar el upgrade ejecutamos el comando esxcli software profile update -p ESXi-8.0U3i-25205845-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-depot.zip –no-hardware-warning una vez que ha finalizado, nos indica que debemos de reiniciar, * NOTA al final explicamos el comando hay temas a tener en cuenta:

• Una vez que el host ha iniciado, lo sacamos del modo mantenimiento:

• Como podemos ver, la actualización se ha realizado correctamente y ya tenemos el host ESXi en la versión 8.0 Update 3i Build 25205845:

• * NOTA a tener en cuenta esxcli software profile update -p ESXi-8.0U3i-25205845-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-depot.zip –no-hardware-warning
• ESXi-8.0U3i-25205845-standard nombre del perfil que contiene la versión y el número de compilación
• VMware-ESXi-8.0U3i-25205845-depot.zip archivo utilizado para la actualización de ESXi
• –no-hardware-warning esta parte es por si nos da un error de CPU, por si la CPU de nuestro equipo no es compatible con la nueva release para que ignore este error, en mi caso la CPU de mi equipo no es compatible 100% con esta nueva reléase por eso lo añado al comando, ya que es un entorno de laboratorio, en producción el comando a ejecutar sería esxcli software profile update -p ESXi-8.0U3i-25205845-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-depot.zip

• Para el segundo host realizamos las mismas operaciones para actualizarlo:

Saludos y espero que os resulte de ayuda

La entrada Actualizar VMware vSphere ESXi 8.0 Update 3h a 8.0 Update 3i con ESXCLI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3i build 25197330, del 2 de marzo de 2026.

En este enlace os dejo la información sobre esta nueva actualización:

• VMware vCenter Server 8.0 Update 3i Release Notes
• Nos conectamos a la interfaz VAMI de nuestro VCSA a través del puerto 5480 e iniciamos sesión:

• Una vez que hemos iniciado sesión podemos ver, que nuestro VCSA está en la versión 8.0.3.00700 build 25092719:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3i, la seleccionamos y damos clic sobre Realizar copias intermedias e instalar:

• Se nos abrirá este asistente, donde aceptamos el EULA, clic a Siguiente:

• Empieza a ejecutar comprobaciones previas a la actualización:

• Omitimos y continuamos:

• Realizamos copias de seguridad del vCenter y finalizamos:

• Como podemos ver comienza el proceso de actualización:

• Como podemos ver, la instalación ha sido completada y correcta:

• Una vez finalizada, volvemos a iniciar sesión en la interfaz VAMI del VCSA a través del puerto 5480, y aquí vemos que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3i build 25197330:

• Ahora accedemos a la interface HTML5 de nuestro VCSA recién actualizado:

• Introducimos las credenciales e iniciamos:

• Aquí podemos ver también que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3i build 25197330:

Saludos y espero que os sea de ayuda

La entrada Actualizar vCenter Server Appliance 8.0 Update 3h a 8.0 Update 3i se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar keycloak con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de PostgreSQL para la base de datos que vamos a utilizar y el otro el propio de keycloak con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

Keycloak es una solución de código abierto para la gestión de identidades y accesos (IAM), diseñada para asegurar aplicaciones y servicios modernos, permite añadir funciones de inicio de sesión único (SSO), autenticación, autorización y federación de usuarios (LDAP/AD, redes sociales) mediante estándares como OpenID Connect, OAuth 2.0 y SAML 2.0.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para keycloak apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de postgreSQL y keycloak:
• sudo mkdir -p /opt/docker/keycloakdb/data
• sudo mkdir -p /opt/docker/keycloakapp/config
• sudo chmod -R 755 /opt/docker/keycloakdb
• sudo chmod -R 755 /opt/docker/keycloakapp

• Al directorio config de /opt/docker/keycloakapp le cambiamos el propietario con sudo chown -R 1000:1000 /opt/docker/keycloakapp/config, con esto le estamos diciendo al sistema, que esta carpeta ahora le pertenece al usuario 1000 (Keycloak), como el contenedor es el dueño, ya tiene permiso total por defecto para crear los archivos de transacciones para los logs:

• Ahora creamos una red para nuestro proyecto, sudo docker network create keycloak-net:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de postgreSQL, para ello, nos situamos en /opt/docker/ keycloakdb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• POSTGRES_DB=keycloak
• POSTGRES_USER=keycloakuser
• POSTGRES_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de postgreSQL en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

keycloak-db:

image: postgres:16.6

container_name: keycloak-db

restart: unless-stopped

env_file: .env

volumes:

– /opt/docker/keycloakdb/data:/var/lib/postgresql/data

networks:

– keycloak-net

networks:

keycloak-net:

name: keycloak-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de keycloak-app, para ello, nos situamos en /opt/docker/keycloakapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• KC_DB=postgres
• KC_DB_URL=jdbc:postgresql://keycloak-db:5432/keycloak
• KC_DB_USERNAME=keycloakuser
• KC_DB_PASSWORD=clave_muy_segura_db
• KEYCLOAK_ADMIN=admkck
• KEYCLOAK_ADMIN_PASSWORD=clave_admin_keycloak

• Nos creamos el fichero docker-compose.yaml para el contenedor de keycloak-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

keycloak-app:

image: quay.io/keycloak/keycloak:26.1.3

container_name: keycloak-app

command:

– start-dev

– –proxy-headers=xforwarded

– –hostname=keycloak.ragasys.net

– –http-enabled=true

– –hostname-strict=false

restart: unless-stopped

env_file: .env

environment:

– KC_DB=${KC_DB}

– KC_DB_URL=${KC_DB_URL}

– KC_DB_USERNAME=${KC_DB_USERNAME}

– KC_DB_PASSWORD=${KC_DB_PASSWORD}

– KEYCLOAK_ADMIN=${KEYCLOAK_ADMIN}

– KEYCLOAK_ADMIN_PASSWORD=${KEYCLOAK_ADMIN_PASSWORD}

volumes:

– /opt/docker/keycloakapp/config:/opt/keycloak/data

networks:

– keycloak-net  # Para comunicar con la DB

– internal-net  # Para comunicar con Nginx Proxy Manager

networks:

keycloak-net:

external: true

internal-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/keycloakdb/.env
• sudo chmod 600 /opt/docker/keycloakapp/.env

• Ahora, iniciamos primero el contenedor de postgreSQL, cd /opt/docker/keycloakdb/, sudo docker compose up -d:

• Iniciamos el contenedor de keycloak-app, cd /opt/docker/keycloakapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para keycloak.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: keycloak-app
• Puerto: 8080
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Rueda configuración avanzada:
• proxy_set_header Host $host;
• proxy_set_header X-Real-IP $remote_addr;
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
• proxy_set_header X-Forwarded-Proto https;
• proxy_set_header X-Forwarded-Ssl on;
• # Esto es vital para que Keycloak no intente redirigir a http interno
• proxy_redirect http:// https://;
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro keycloak a través de nuestro proxy inverso con Nginx Proxy Manager:

• Nos hemos creado un nuevo realm para nuestras aplicaciones:

• El rol del Realm master, el realm master es puramente para la administración del servidor de Keycloak.
• Se usa para crear otros Realms.
• Se usa para crear usuarios que sean administradores globales.
• Regla de oro, no registres tus aplicaciones (como phpIPAM, Nextcloud, etc.) ni a tus usuarios finales dentro de master.
• Por qué crear un Realm nuevo (Ragasys-Apps), al crear un realm específico para tus aplicaciones:
• Aislamiento, si te equivocas configurando algo en el realm de tus apps, el acceso de administración en master sigue funcionando.
• Seguridad, puedes tener políticas de contraseñas y 2FA distintas para los administradores en el master y para los usuarios en el nuevo realm.
• Orden, mantemos limpios los logs y la base de datos de usuarios.
• Sobre el real que hemos creado, accedemos a Authentication > Required actions > Configure OTP habilitamos Configure OTP y Set as default action, esto obligará a configurar el 2FA a todos los usuarios:

Saludos y espero que os sea de ayuda

La entrada Desplegar keycloak con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar phpIPAM con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de phpIPAM con la aplicación.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para phpIPAM apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de mariadb y phpipam:
• sudo mkdir -p /opt/docker/mariadb/data
• sudo mkdir -p /opt/docker/mariadb/config
• sudo mkdir -p /opt/docker/phpipam/config
• sudo chmod -R 755 /opt/docker/mariadb /opt/docker/phpipam

• Ahora creamos una red para nuestro proyecto, sudo docker network create phpipam-net:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en /opt/docker/mariadb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=una_clave_muy_segura_root
• MYSQL_DATABASE=phpipam
• MYSQL_USER=phpipamuser
• MYSQL_PASSWORD=clave_usuario_phpipam

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

phpipam-db:

image: mariadb:latest

container_name: phpipam-db

restart: unless-stopped

env_file: .env

ports:

– «3306:3306»

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/mariadb/data:/var/lib/mysql

– /opt/docker/mariadb/config:/etc/mysql/conf.d:ro

networks:

– phpipam-net

networks:

phpipam-net:

name: phpipam-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de phpIPAM, para ello, nos situamos en /opt/docker/phpipam, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• IPAM_DATABASE_HOST=192.168.14.17 # IP docker02
• IPAM_DATABASE_USER=phpipamuser
• IPAM_DATABASE_PASS=clave_usuario_phpipam
• IPAM_DATABASE_NAME=phpipam
• IPAM_DATABASE_PORT=3306
• IPAM_BASE_URL=https://phpipam.ragasys.net
• PHPIPAM_TRUSTED_PROXIES=192.168.14.0/24 # Rango de red de docker01
• # IPAM_DISABLE_INSTALLER=1 Luego lo habilitamos

• Nos creamos el fichero docker-compose.yaml para el contenedor de phpIPAM en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

phpipam-web:

image: phpipam/phpipam-www:latest

container_name: phpipam-web

restart: unless-stopped

ports:

– «8080:80»

env_file: .env

environment:

– IPAM_DATABASE_HOST=${IPAM_DATABASE_HOST}

– IPAM_DATABASE_USER=${IPAM_DATABASE_USER}

– IPAM_DATABASE_PASS=${IPAM_DATABASE_PASS}

– IPAM_DATABASE_NAME=${IPAM_DATABASE_NAME}

– IPAM_DATABASE_PORT=${IPAM_DATABASE_PORT}

volumes:

– /opt/docker/phpipam/config:/copy-to-www-html

networks:

– phpipam-net

networks:

phpipam-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/mariadb/.env
• sudo chmod 600 /opt/docker/phpipam/.env

• Ahora, iniciamos primero el contenedor de MariaDB, cd /opt/docker/mariadb/, sudo docker compose up -d:

• Iniciamos el contenedor de phpIPAM, cd /opt/docker/phpipam/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps:

• Accedemos a nuestro contenedor phpIPAM, http://192.168.14.17:8080:

• Voy a migrar de un servidor antiguo que tengo con phpIPAM v1.4, para ello, he realizado un backup de la base de datos que utilizaba este servidor, mysqldump -u phpipam -p phpipam > MIGRATE.sql:

• Copiamos el backup de la base de datos en /opt/docker/mariadb:

• Importamos los datos directamente al contenedor de MariaDB, sudo docker exec -i phpipam-db mariadb -u phpipamuser -p’passworduserdb’ phpipam < /opt/docker/mariadb/MIGRATE.sql:

• Ahora, accedemos a la interfaz web de phpipam y seleccionamos la opción 3, Working installation:

• Introducimos las credenciales de la base de datos que hemos migrado, es decir, la de nuestro servidor phpipam antiguo:

• Y le hacemos un Upgrade a la base de datos:

• Vemos que el Upgrade ha sido correcto, damos clic a Dashboard y vemos que ya tenemos nuestro phpIPAM operativo y migrado de nuestro servidor antiguo:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para phpIPAM.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: IP máquina docker02
• Puerto: 8080
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Como el phpIPAM lo tenemos detrás de un proxy inverso, tenemos que seguir estos pasos para que nos funcione y podamos acceder a la web de administración:
• Sobre Administración > phpIPAM settings configuramos la URL del sitio y guardamos:

• Con sudo docker exec -it phpipam-web sh entramos al contenedor:

• Con apk add –no-cache nano, instalamos el editor nano:

• Accedemos al directorio phpipam y editamos el fichero nano config.docker.php:

• Al final del fichero añadimos estas líneas:

/* — CONFIGURACIÓN FORZADA PARA PROXY Y BASE DE DATOS — */

// 1. Forzar que phpipam sepa que está en la raíz y es HTTPS

define(‘BASE’, «/»);

$_SERVER[‘HTTPS’] = ‘on’;

$_SERVER[‘SERVER_PORT’] = 443;

// 2. Forzar los datos de la Base de Datos (ajusta si tus datos son distintos)

$db[‘host’] = ‘192.168.14.17’;

$db[‘user’] = ‘phpipamuser’;

$db[‘pass’] = ‘phpipampass’; // <— PON AQUÍ TU CONTRASEÑA REAL

$db[‘name’] = ‘phpipam’;

$db[‘port’] = 3306;

/** Disable installation helper **/

define(‘TOOLKIT’, true);

$disable_installer = true;

• Con rm -f config.php y ln -s config.docker.php config.php borramos el enlace simbólico y lo volvemos a crear, con exit salimos del contenedor:

• Como hemos modificado un fichero dentro del contenedor docker de phpIPAM, ese mismo fichero lo guardamos en el volumen que creamos en el docker-compose.yaml, así cuando actualicemos el contenedor, ese fichero también será modificado dentro del contenedor actualizado, sudo docker cp phpipam-web:/phpipam/config.docker.php /opt/docker/phpipam/config/config.docker.php:

• Modificamos de nuevo el fichero docker-compose de phpIPAM con sudo nano docker-compose.yaml y añadimos las líneas:

– /opt/docker/phpipam/config/config.docker.php:/phpipam/config.docker.php:ro

– /opt/docker/phpipam/config/config.docker.php:/phpipam/config.php:ro

• Con sudo docker exec -it phpipam-db mariadb -u root -p accedemos al contenedor de MariaDB:

• Y ejecutamos:
• USE phpipam;
• UPDATE settings SET siteURL = ‘https://phpipam.ragasys.net/’ WHERE id = 1;
• UPDATE settings SET prettyLinks = ‘Yes’ WHERE id = 1;
• exit;

• Sobre la configuración del host de phpipam que configuramos en Nginx Proxy Manager, debemos de agregar esta configuración personalizada:

# Forzar cabeceras de protocolo seguro

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto https;

proxy_set_header X-Forwarded-Ssl on;

# Evitar que el backend envíe redirecciones a http

proxy_redirect http:// https://;

# Desactivar compresión si da problemas con sub_filter

proxy_set_header Accept-Encoding «»;

# Cambiar cualquier mención de http por https en el código de la página

sub_filter ‘http://phpipam.ragasys.net’ ‘https://phpipam.ragasys.net’;

sub_filter_once off;

• Con sudo docker restart phpipam-web reiniciamos el contenedor de phpIPAM:

• Modificamos de nuevo el .env de phpIPAM, cd /opt/docker/phpipam/, nano .env:

• Y descomentamos la línea IPAM_DISABLE_INSTALLER=1:

• Reiniciamos el contenedor de phpIPAM con sudo docker compose up -d:

• Y como vemos ya tenemos acceso a nuestro phpIPAM a través de nuestro proxy inverso con Nginx Proxy Manager:

Saludos y espero que os sea de ayuda

La entrada Desplegar phpIPAM con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar homepage con Docker.

Homepage es un panel de control de aplicaciones moderno, totalmente estático, rápido, seguro, con proxy completo y altamente personalizable, con integraciones para más de 100 servicios y traducciones a varios idiomas, se configura fácilmente mediante archivos YAML o mediante la detección de etiquetas Docker.

• Nos creamos el registro DNS del tipo CNAME para homepage apuntando a la máquina que tiene instalada el Docker:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de homepage:
• sudo mkdir -p /opt/docker/homepage/config
• sudo mkdir -p /opt/docker/homepage/icons
• sudo mkdir -p /opt/docker/homepage/images
• sudo chmod -R 775 /opt/docker/homepage

• Así quedaría nuestra estructura de directorios:

• Lo siguiente que haremos será crearnos el archivo docker-compose.yml para homepage, sudo nano /opt/docker/homepage/docker-compose.yml:

• Iniciamos Nginx Proxy Manager, cd /opt/docker/homepage, sudo docker compose up -d:

• Con sudo docker ps -a, vemos el contenedor levantado:

• Con docker exec -it nginxpm sh -c «apk add –no-cache curl >/dev/null 2>&1; curl -sI http://homepage:3000«, comprobamos que Nginx Proxy Manager puede acceder a homepage:

• Ahora nos vamos al panel de administración de Nginx Proxy Manager para crear el Proxy Host:

• Add Proxy Host:

• En la pestaña Details:
• Domain Names: ragasys.eu
• Scheme: http
• Forward Hostname / IP: homepage
• Forward Port: 300
• Websockets Support
• Block Common Exploits
• En la pestaña SSL:
• Seleccionamos en Certificate nuestros certificados SSL
• Marcamos Force SSL
• Marcamos HTTP/2 Support
• Save

• Aquí vemos el host creado y online:

• Si accedemos al host homepage, vemos que ya está utilizando los certificados SSL de Let’s Encrypt, vemos también que nos da un error de validación, es un error bastante común la primera vez que accedemos a Homepage (detrás de un proxy inverso como Nginx Proxy Manager, ahora veremos cómo solucionarlo:

• Para solucionar este error vamos a editar el fichero settings.yml, sudo nano /opt/docker/homepage/docker-compose.yml:

• Y añadimos la variable, HOMEPAGE_ALLOWED_HOSTS: «homepage.ragasys.net,localhost,127.0.0.1»:

• Aplicamos los cambios, cd /opt/docker/homepage, docker compose up -d:

• Accedemos a nuestro host, https://homepage.ragasys.net y vemos que ya tenemos el panel de homepage:

• Ahora vamos a ir configurando los distintos ficheros de homepage, para ir personalizando nuestro panel, esta será la estructura de directorios y los ficheros:

• Empezaremos por el fichero sudo nano settings.yaml:

• sudo nano services.yaml, aquí muestro algunos ejemplos que tenemos que ir completando con todo lo que tenemos en nuestra infraestructura:

• sudo nano widgets.yaml, los widgets para el dashboard:

• sudo nano bookmarks.yaml, los enlaces personales para el dashboard:

• Y así nos iría quedando nuestro panel de Homepage:

Saludos y espero que os sea de ayuda

La entrada Desplegar homepage con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como Actualizar Nginx Proxy Manager con Docker.

• Lo primero que vamos a ver es que versión de Nginx Proxy Manager tenemos instalada, para ello, ejecutamos docker exec nginxpm cat package.json | grep version:

• Ahora actualizamos a la versión más reciente.
• cd /opt/docker/nginxpm
• docker compose pull nginxproxymanager
• docker compose up -d
• Descarga la nueva versión
• Detiene el contenedor actual
• Lo recrea con la nueva imagen, manteniendo toda la configuración, certificados, bases de datos, etc…
  porque están montados como volúmenes:
• volumes:
• /opt/docker/nginxpm/data:/data
• /opt/docker/nginxpm/data/letsencrypt:/etc/letsencrypt
• /opt/docker/nginxpm/certs:/opt/custom-certs:ro

• Volvemos a ejecutar docker exec nginxpm cat package.json | grep version y vemos que tenemos actualizada a la última versión disponible de Nginx Proxy Manager:

• Si hacemos un docker images vemos las imágenes disponibles en nuestro sistema y con docker ps -a vemos la imagen que está en uso para nuestro Nginx Proxy Manager:

• Con docker rmi imageID podemos eliminar las imágenes que ya no están en uso, en este caso eliminamos la imagen antigua de Nginx Proxy Manager que ya no utilizamos:

• Cuando actualizamos la versión de Nginx Proxy Manager, nos podemos encontrar con este error al renovar nuestros certificados de Let´s Encrypt, Internal error:

• El problema viene dado por las versiones de certbot, que utilizan las nuevas versiones, certbot es el encargado de renovar nuestros certificados de Let’s Encrypt, para solucionarlo, en el fichero docker-compose.yaml debemos de agregar esta línea:

environment:

      – PIP_BREAK_SYSTEM_PACKAGES=1

• Destruimos el contenedor con sudo docker compose down:

• Lo levantamos de nuevo con la nueva variable de entorno, sudo docker compose up -d:

• Inyectamos el bloque definitivo por última vez en caliente, sudo docker exec -it nginxpm bash:

/opt/certbot/bin/pip install –force-reinstall –no-cache-dir \

«cryptography==43.0.3» \

«pyOpenSSL==25.0.0» \

«josepy==1.15.0» \

«acme==3.3.0» \

«certbot==3.3.0» \

«certbot-dns-azure» \

«certbot-dns-cloudflare»

exit

• Aplicamos un reinicio de servicio al contenedor, sudo docker restart nginxpm:

• Ya podemos renovar nuestros certificados sin problemas:

Saludos y espero que os sea de ayuda

La entrada Actualizar Nginx Proxy Manager con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como añadir certificados SSL personalizados en Nginx Proxy Manager.

• Para empezar, copiamos nuestros certificados wildcard en el directorio de certificados de Nginx Proxy Manager, separamos el fichero .pfx para obtener el certificado público por un lado .crt, y la clave privada por otro .key, para ello vamos a introducir los comandos:
• openssl pkcs12 -in wildcard_ragasys_net.pfx -clcerts -nokeys -out wildcard_ragasys_net.crt
• openssl pkcs12 -in wildcard_ragasys_net.pfx -nocerts -nodes -out wildcard_ragasys_net.key
• openssl pkcs12 -in wildcard_ragasys_net.pfx -cacerts -nokeys -out wildcard_ragasys_net_chain.crt

• Con este último comando (openssl pkcs12 -in wildcard_ragasys_net.pfx -cacerts -nokeys -out wildcard_ragasys_net_chain.crt) me va a dar el contenido del .crt vacío (en blanco), ya que es una entidad certificadora que he desplegado desde el Active Directory, con los certificados comprados a una entidad certificadora oficial no tendríamos este problema.
• Para solucionarlo, debo exportar el certificado de mi entidad certificadora:

• Se nos abre este asistente, Siguiente:

• Seleccionamos X.509 codificado base 64 (.CER), Siguiente:

• Le indicamos la ruta para guardarlo, Siguiente:

• Finalizamos:

• Y copiamos el contenido de este fichero .cer en el fichero .crt que estaba en blanco:

• Con esto ya tengo preparado, los tres ficheros que necesito para subirlos al Nginx Proxy Manager como certificados personalizados, .crt (clave pública), .key (clave privada) y el certificado intermedio:

• Ahora, dentro de la consola web de Nginx Proxy Manager, accedemos a Certificados > Añadir Certificado > Certificado Personalizado:

• Le indicamos un nombre y añadimos nuestros certificados (clave privada, clave pública y certificado intermedio), Guardar:

• Como podemos ver, ya lo tenemos añadido y listo para usar con nuestros hosts:

• Como podemos ver, en la ruta /opt/docker/nginxpm/data/custom_ssl nos guarda los certificados personalizados:

Saludos y espero que os resulte de ayuda

La entrada Certificados SSL personalizados en Nginx Proxy Manager se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como agregar los Hosts en Nginx Proxy Manager utilizando los certificados SSL que hemos desplegado.

• Accedemos a Hosts > Proxy Hosts:

• Add Proxy Host:

• En la pestaña Details:
• Domain Names: ragasys.eu
• Scheme: http
• Forward Hostname / IP: IP
• Forward Port: 80
• Websockets Support
• Block Common Exploits
• En la pestaña SSL:
• Seleccionamos en Certificate nuestros certificados SSL
• Marcamos Force SSL
• Marcamos HTTP/2 Support
• Save

• Aquí vemos el host creado y online:

• Si accedemos al host, vemos que ya está utilizando los certificados SSL de Let’s Encrypt:

• Agregamos más hosts a medida que los vamos necesitando:

• En nuestro DNS interno, nos hemos creado estos registros del tipo CNAME apuntando a la máquina que tiene el contenedor Docker de nginx proxy manager:

• Si accedemos a SSL Certificates, vemos que ya tenemos los certificados en uso, una vez creados los hosts:

• Ahora vamos a crear otro host para el propio portal de Nginx Proxy Manager puerto 81 y le haremos la redirección para utilizar un certificado SSL:

• Aquí lo tenemos creado:

• Accedemos por https:

• Vemos que ya está utilizando el certificados SSL de Let’s Encrypt:

Saludos y espero que os sea de ayuda

La entrada Agregar Hosts en Nginx Proxy Manager se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como añadir certificados SSL de Let’s Encrypt en Nginx Proxy Manager configurados por DNS Challenge y como DNS Provider utilizaremos Azure, que es dónde tenemos alojada nuestra zona DNS.

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Azure para Let’s Encrypt, para ello, accedemos a Zonas DNS > ragasys.eu > Administración de DNS > Registros > Agregar:

• Ahora en nuestra nuestra zona DNS de Azure y debemos de tener en cuenta estos datos:
• Nombre exacto de la zona
• Grupo de recursos donde se encuentra
• Id. de suscripción

• Creamos una aplicación, para ello, accedemos a Microsoft Entra ID > Registro de aplicaciones > Nuevo registro:

• Le indicamos el Nombre y Solo cuentas de este directorio organizativo (Inquilino único), Registrar:

• Aquí tenemos la aplicación creada:

• Ahora vamos a crear el secreto de cliente, para ello, en esta nueva aplicación, accedemos a Administrar > Certificados y secretos > Secretos de los clientes > Nuevo secreto de cliente:

• Le indicamos una descripción y el tiempo de expiración, Agregar:

• Aquí tenemos el secreto de cliente, lo copiamos y guardamos en un lugar seguro, ya que sólo nos lo mostrará una sola vez:

• Sobre la Información general de la aplicación, anotamos los siguientes valores, que serán los que utilice Nginx Proxy Manager para el DNS Challenge:

• Ahora damos permisos a la aplicación sobre la Zona DNS, con esto, nuestra aplicación ya tiene permiso para crear/eliminar registros TXT dentro de la zona ragasys.eu, el rol que debemos asignar es el de Colaborador de zona DNS:

• Como la zona ragasys.eu también la tenemos en nuestro DNS interno, nos creamos el registro CNAME _acme-challenge apuntando a _acme-challenge.ragasys.eu, para que resuelva externamente hacia Azure:

• Con esto, ya tenemos preparado la parte de la zona DNS de Azure, ahora accedemos al portal de Nginx Proxy Manager > SSL Certificates > Add SSL Certificate > Let’s Encrypt y vamos a añadir las configuraciones para obtener el certificado wildcard para para nuestro dominio:

• Añadimos Let’s Encrypt:
• Domain Names, añadimos ragasys.eu y *.ragasys.neu, nos aseguramos de incluir el dominio raíz y el wildcard, Let’s Encrypt requiere que se valide también la raíz cuando pedimos el wildcard.
• Email Address for Let’s Encrypt
• Marcamos Use a DNS Challenge.
• En DNS Provider seleccionanamos Azure.
• Rellenaremos los valores para estos campos, Tenant ID, Client ID, Client Secret, Subscription ID, Resource Group, Zone Name.
• Propagation Seconds, ponemos un valor entre 300 y 600.
• Marcamos I Agree to Let’s Encrypt Terms of Service y pulsamos Save, Nginx Proxy Manager iniciará el proceso ACME, creará el TXT _acme-challenge en la zona DNS de Azure, esperará la propagación y Let’s Encrypt validará.
• Este es el contenido del Credentials File Content:
• dns_azure_sp_client_id =
• dns_azure_sp_client_secret =
• dns_azure_tenant_id =
• dns_azure_zone1 = ragasys.eu:/subscriptions/eliddemisuscripcion/resourceGroups/zonasdnspublicas-rg/providers/Microsoft.Network/dnsZones/ragasys.eu

• Este es el registro TXT _acme-challenge que se genera, Let’s Encrypt valida que el TXT coincida con el valor que generó para esa verificación, después de emitir el certificado, Nginx Proxy Manager debería borrar automáticamente el TXT de la zona si todo funciona bien:

• Aquí podemos ver, los certificados SSL de Let’s Encrypt con Azure como DNS Provider, listos para usar en nuestros Hosts:

Saludos y espero que os sea de ayuda

La entrada Certificados SSL Let’s Encrypt en Nginx Proxy Manager y Azure como DNS Provider se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como añadir certificados SSL de Let´s Encrypt en Nginx Proxy Manager configurados por DNS Challenge y como DNS Provider utilizaremos Cloudflare, que es dónde tenemos alojadas nuestras zonas DNS.

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Cloudflare para Let´s Encrypt, para ello, accedemos a DNS > Registros > Agregar registro:

• Ahora vamos a crear un API Token en nuestra zona DNS de Cloudflare, accedemos a Mi Perfil > Tokens de API > Crear Token:

• Seleccionamos Editar zona DNS > Usar plantilla, también podemos usar Crear Token Personalizado:

• Le indicamos un nombre para el token, le indicamos los permisos, los recursos de zona, Ir al resumen:

• Nos muestra un resumen y creamos el token para nuestra zona:

• Aquí tenemos el token generado, debemos de copiar el valor, ya que lo mostrará sólo una vez, guardamos el token en un sitio seguro:

• Verificamos el token y vemos que es válido:

• Aquí vemos que ya tenemos el token activo:

• Con esto, ya tenemos preparado la parte de la zona DNS de Cloudflare, ahora accedemos al portal de Nginx Proxy Manager > SSL Certificates > Add SSL Certificate > Let’s Encrypt y vamos a añadir las configuraciones para obtener el certificado wildcard para para nuestro dominio:

• Añadimos Let’s Encrypt:
• Domain Names, añadimos ragasys.net y *.ragasys.net, nos aseguramos de incluir el dominio raíz y el wildcard, Let’s Encrypt requiere que se valide también la raíz cuando pedimos el wildcard.
• Email Address for Let’s Encrypt, nuestro email registrado en Cloudflare.
• Marcamos Use a DNS Challenge.
• En DNS Provider seleccionanamos Cloudflare.
• Pegamos el API Token que copiamos desde Cloudflare.
• Propagation Seconds, ponemos un valor entre 300 y 600).
• Marcamos I Agree to Let’s Encrypt Terms of Service y pulsamos Save, Nginx Proxy Manager iniciará el proceso ACME, creará el TXT _acme-challenge en Cloudflare, esperará la propagación y Let’s Encrypt validará.

• Aquí podemos ver los certificados SSL de Let’s Encrypt con Cloudflare como DNS Provider listos para usuar en nuestros Hosts:

• Estos son los registros TXT _acme-challenge que se generan, Let’s Encrypt valida que el TXT coincida con el valor que generó para esa verificación, después de emitir el certificado, Nginx Proxy Manager debería borrar automáticamente el TXT de la zona si todo funciona bien:

• Tengo otro dominio DNS llamado ragasyssistemas.com en cloudflare, y también quiero añadir a Nginx Proxy Manager los certificados SSL de Let’s Encrypt para este dominio, para ello, vuelvo a repetir todo el proceso, y aquí vemos, que ya los tengo agregados y listos para usar en nuestros Hosts:

Saludos y espero que os resulte de ayuda

La entrada Certificados SSL Let´s Encrypt en Nginx Proxy Manager y Cloudflare como DNS Provider se publicó primero en RAGASYS SISTEMAS.