| ... | ... | @@ -22,7 +22,7 @@ Como resultado, readaptamos todas nuestra mejoras a la nueva estructura del role |
|
|
|
|
|
|
|
## Plan
|
|
|
|
|
|
|
|
El servidor OpenVPN en producción se encuentra en un host independiente (contenedor LXC) creado también a partir de nuestros *playbooks* Ansible, por lo cual todo su contenido está representado y es generable a través de código (a excepción de las claves criptográficas, ver párrafo siguiente). Esto nos permitirá realizar la migración rápidamente y de la forma mas limpia: destruir el antiguo contenedor Strectch (previo bacukup Proxmox por prevención) y reemplazarlo por uno nuevo a partir de una imagen de Buster.
|
|
|
|
El servidor OpenVPN en producción se encuentra en un host independiente (contenedor LXC) creado también a partir de nuestros *playbooks* Ansible, por lo cual todo su contenido está representado y es generable a través de código (a excepción de las claves criptográficas, ver párrafo siguiente). Esto nos permitirá realizar la migración rápidamente y de la forma mas limpia: destruir el antiguo contenedor Stretch (previo bacukup Proxmox por prevención) y reemplazarlo por uno nuevo a partir de una imagen de Buster. Una vez se tenga definida la hora programada para detener, respaldar y destruir el contenedor, se notificará a los usuarios vía correo electrónico para que estén al tanto de la indisponibilidad momentánea del servicio VPN.
|
|
|
|
|
|
|
|
Lo único que es necesario respaldar del contenedor a destruir para recuperar en el nuevo, son las claves criptográficas del servidor y de los clientes. Esto con el objetivo de que la migración sea invisible para los usuarios. Bien podrían generarse llaves nuevas para todos los usuarios y distribuirlas a sus propietarios para que reconfiguren sus clientes.
|
|
|
|
|
| ... | ... | |
| ... | ... | |
