| ... | ... | @@ -96,35 +96,114 @@ Estos serán los pasos que daremos al migrar el PWM. |
|
|
|
* Al momento `chalchal` se encuentra creado y contiene almacenadas sus llaves DKIM que permiten al Postfix enviar mails firmados. Además estas llaves ya se encuentran publicadas en el DNS. Por esta razón, conviene respaldar las llaves existentes para volver a restaurarlas una vez que se recree el contenedor. Concretamente respaldaremos el directoio `/etc/opendkim`.
|
|
|
|
* Además haremos un respaldo Proxmox previo del contenedor por si fuese necesario.
|
|
|
|
|
|
|
|
#### Operaciones sobre el LDAP
|
|
|
|
#### Instalación y configuración del servidor
|
|
|
|
|
|
|
|
* Junto a la migración del PWM, se incorporarán nuevos grupos al LDAP, así como nuevos miembros a los mismos.
|
|
|
|
* Para realizar estas operaciones, en el servidor OpenLDAP de producción (`ldap.interior.edu.uy`), se debe ejecutar el script de administración general del LDAP así: `./Admin_LDAP.sh`
|
|
|
|
* En primer lugar creamos el nuevo grupo `matrix_externos`. Para esto, elegimos la opción *4*, indicamos nombre de grupo y listo.
|
|
|
|
* A este nuevo grupo y al grupo `gitlab` se incorporará la **totalidad** de los usuarios existentes registrados en nuestro LDAP. Para efecutar la primera incorporación automática de estos usuarios, elegimos la opción *11*, indicamos nombre de grupo (una vez con `matrix_externos` y otra por `gitlab`) e ingresamos *all*.
|
|
|
|
* Por otro lado, agregaremos al grupo `eduroam` a todos los usuarios registrados con cuentas de mails de dominios **pertenecientes** a la UdelaR. Para esto, elegimos la opción *11*, indicamos nombre de grupo (`eduroam`) e ingresamos *udelar*.
|
|
|
|
* Por último, agregaremos al grupo `matrix` a todos los usuarios registrados con cuentas de mails de dominios **pertenecientes** a la Red de Unidades Informáticas del Interior. Para esto, elegimos la opción *11*, indicamos nombre de grupo (`matrix`) e ingresamos *interior*.
|
|
|
|
* Bajar los TTLS en la zona DNS `interior.edu.uy` e `interior.udelar.edu.uy` (ver [esto](https://git.interior.edu.uy/adminsys/config/-/wikis/Migraci%C3%B3n-del-Owncloud-9.1-de-nube.interior.edu.uy-a-un-NextCloud-16#bajar-los-ttls-en-la-zona-dns-interioreduuy)).
|
|
|
|
* Actualización de la rama de trabajo con los últimos commits de master (ver [esto](https://git.interior.edu.uy/adminsys/config/-/wikis/Migraci%C3%B3n-del-Owncloud-9.1-de-nube.interior.edu.uy-a-un-NextCloud-16#actualizaci%C3%B3n-de-la-rama-41-con-los-%C3%BAltimos-cambios-hechos-en-master)).
|
|
|
|
|
|
|
|
* Se crea el contenedor, se instala y configura el PWM mediante el playbook site.yml (ver [esto](https://git.interior.edu.uy/adminsys/config/-/wikis/Migraci%C3%B3n-del-Owncloud-9.1-de-nube.interior.edu.uy-a-un-NextCloud-16#creaci%C3%B3n-del-contenedor-candombe-mediante-ansible)):
|
|
|
|
|
|
|
|
#### Instalación y configuración del servidor
|
|
|
|
* Se comenta la mac en las host_vars
|
|
|
|
* Se remueve timbo de las known_hosts locales:
|
|
|
|
|
|
|
|
* Bajar los TTLS en la zona DNS `interior.edu.uy`.
|
|
|
|
* Actualización de la rama de trabajo con los últimos commits de master (ver [esto](https://git.interior.edu.uy/adminsys/config/-/wikis/Migraci%C3%B3n-del-Owncloud-9.1-de-nube.interior.edu.uy-a-un-NextCloud-16#actualizaci%C3%B3n-de-la-rama-41-con-los-%C3%BAltimos-cambios-hechos-en-master)).
|
|
|
|
```
|
|
|
|
ssh-keygen -f "/home/apias/.ssh/known_hosts" -R 164.73.98.42
|
|
|
|
ssh-keygen -f "/home/apias/.ssh/known_hosts" -R 2001:1328:6a::42
|
|
|
|
ssh-keygen -f "/home/apias/.ssh/known_hosts" -R chalchal.interior.edu.uy
|
|
|
|
ssh-keygen -f "/home/apias/.ssh/known_hosts" -R chalchal
|
|
|
|
ssh-keygen -f "/home/apias/.ssh/known_hosts" -R login.interior.edu.uy
|
|
|
|
ssh-keygen -f "/home/apias/.ssh/known_hosts" -R login
|
|
|
|
```
|
|
|
|
|
|
|
|
* Se crea el contenedor, se instala y configura el PWM mediante el playbook site.yml (ver [esto](https://git.interior.edu.uy/adminsys/config/-/wikis/Migraci%C3%B3n-del-Owncloud-9.1-de-nube.interior.edu.uy-a-un-NextCloud-16#creaci%C3%B3n-del-contenedor-candombe-mediante-ansible)). Concretamente se lanza el playbook:
|
|
|
|
* Se lanza el playbook:
|
|
|
|
|
|
|
|
`ansible-playbook --limit chalchal.interior.edu.uy site.yml -vv -i hosts_prod --skip-tags descarga`
|
|
|
|
`ansible-playbook --limit chalchal.interior.edu.uy site.yml -vv -i hosts_prod --skip-tags descarga`
|
|
|
|
|
|
|
|
* Se hacen chequeos mínimos para verificar que el PWM funciona de forma correcta en conjunto con `ldap-test.interior.edu.uy`.
|
|
|
|
|
|
|
|
* Luego se actualiza la configuración del servicio para que apunte a `ldap.interior.edu.uy`.
|
|
|
|
|
|
|
|
#### Llaves Opendkim
|
|
|
|
|
|
|
|
La configuración de llaves dkim es necesaria para que los mails se envién firmados desde el servidor. Estas llaves han sido generadas para instancias previas de `chalchal` y se encuentran publicadas en la zona `interior.edu.uy`, por lo que las tenemos respaldas. Al recrear `chalchal` se volvieron a regenerar. A continuación procederemos a restaurarlas desde nuestros respaldos.
|
|
|
|
|
|
|
|
* Primero que nada movemos o vaciamos el directorio keys así:
|
|
|
|
|
|
|
|
```
|
|
|
|
root@chalchal:/etc/opendkim# mv keys /root/
|
|
|
|
```
|
|
|
|
|
|
|
|
* Luego restauramos el directorio `keys` hacia `/etc/opendkim` desde un respaldo en che o desde nuestra PC.
|
|
|
|
|
|
|
|
* Finalmente hay que ajustar permisos para el directorio `keys` y para cada uno de sus subdirectorios (dominios) de la siguiente manera. Además habrá que cambiar propietario y grupo para cada uno de los archivos `email.private`.
|
|
|
|
|
|
|
|
```
|
|
|
|
root@chalchal:/etc/opendkim# chmod -R 755 keys
|
|
|
|
root@chalchal:/etc/opendkim# cd keys/login.interior.edu.uy
|
|
|
|
root@chalchal:/etc/opendkim/keys/login.interior.edu.uy# chmod 600 *
|
|
|
|
root@chalchal:/etc/opendkim/keys/login.interior.edu.uy# chown opendkim:opendkim email.private
|
|
|
|
...
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Varela en Modo mantenimiento
|
|
|
|
|
|
|
|
* Se crea una página web estática en `/var/www/html/pwm/index.html`.
|
|
|
|
* Esta funcionará como página de mantenimiento que informará a los usuarios sobre las horas de comienzo y fin de la migración. Además les indicará que ahora deberán dirigirse a `login.interior.edu.uy` para poder registrarse. A su vez está página (mediante headers html) hará una redirección HTTP hacia `login.interior.edu.uy` luego de transcurrido unos segundos.
|
|
|
|
* **Momento crítico de la migración**. Se debe determinar cuando poner en mantenimiento la instancia de PWM de `varela`, para ello elegir un momento en que no haya actividad de usuarios en el sitio (revisar los logs para detectar si hay algún usuario registrándose en el sitio en determinado momento).
|
|
|
|
* Cuando llegue este momento, editar el virtualhost de Apache para deshabilitar el Reverse Proxy. De esta manera, Tomcat y PWM seguirán en funcionamiento pero serán inalcanzables. Esto permitirá que el usuario llegue en primer lugar a la página de mantenimiento.
|
|
|
|
* Se creará una una web estática que funcionará como página de mantenimiento e informará a los usuarios sobre las horas de comienzo y fin de la migración. Esta además indicará que deberán dirigirse a `login.interior.edu.uy` para poder registrarse. A su vez está página (mediante headers html) hará una redirección HTTP hacia `login.interior.edu.uy` luego de transcurrido unos segundos.
|
|
|
|
* La misma deberá ser colocada en las rutas `/var/www/html/index.html` y `/var/www/html/pwm/index.html`
|
|
|
|
* **Momento crítico de la migración**. Se debe determinar cuando poner en mantenimiento la instancia de PWM de `varela`, para ello elegir un momento en que no haya actividad de usuarios en el sitio.
|
|
|
|
* Para poder obtener mayor información de la actividad de los usuarios se deben setear el modo *TRACE* en la configuración de todos los logs del PWM de `varela`.
|
|
|
|
* En general, se detecta actividad en el sitio cuando aparecen nuevas líneas en los logs de forma constante. Esto puede ser chequeado con este comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
root@varela:/home/apias# tail -F /var/lib/tomcat7/logs/catalina.out
|
|
|
|
```
|
|
|
|
|
|
|
|
* Para conocer si hay algún usuario registrándose en este momento en el sitio podemos usar lo siguiente:
|
|
|
|
|
|
|
|
```
|
|
|
|
root@varela:/home/apias# tail -F /var/lib/tomcat7/logs/catalina.out | grep NewUser
|
|
|
|
```
|
|
|
|
|
|
|
|
Un evento de registro tendrá el siguiente aspecto:
|
|
|
|
|
|
|
|
```
|
|
|
|
2020-12-11 17:49:44, TRACE, pwm.SessionFilter, {2396} GET request for: /pwm/public/NewUser (no params) [164.73.88.22]
|
|
|
|
```
|
|
|
|
|
|
|
|
* Si alguién se ha autenticado recientemente lo podemos detectar así:
|
|
|
|
|
|
|
|
```
|
|
|
|
root@varela:/home/apias# tail -F /var/lib/tomcat7/logs/catalina.out | grep authenticated
|
|
|
|
```
|
|
|
|
|
|
|
|
* Cuando llegue este momento, editar los virtualhosts de Apache para deshabilitar el Reverse Proxy. De esta manera, Tomcat y PWM seguirán en funcionamiento pero serán inalcanzables. Esto permitirá que el usuario llegue en primer lugar a la página de mantenimiento.
|
|
|
|
* Se edita el vhost `identidad.interior.edu.uy-revpxy-ssl.conf` así:
|
|
|
|
* Se comentan estas líneas:
|
|
|
|
|
|
|
|
```
|
|
|
|
#Redirect "/" "https://identidad.interior.edu.uy/pwm"
|
|
|
|
|
|
|
|
#<Location /pwm>
|
|
|
|
# ProxyPass http://identidad.interior.edu.uy:8080/pwm
|
|
|
|
# ProxyPassReverse http://identidad.interior.edu.uy:8080/pwm
|
|
|
|
#</Location>
|
|
|
|
```
|
|
|
|
|
|
|
|
* Además se activa la directiva DocumentRoot así:
|
|
|
|
|
|
|
|
```
|
|
|
|
DocumentRoot /var/www/html/pwm
|
|
|
|
```
|
|
|
|
* Se edita el vhost `identidad.interior.udelar.edu.uy-ssl.conf`, activando la directiva DocumentRoot así:
|
|
|
|
|
|
|
|
```
|
|
|
|
DocumentRoot /var/www/html/pwm
|
|
|
|
```
|
|
|
|
* Finalmente se reinicia apache:
|
|
|
|
|
|
|
|
```
|
|
|
|
service apache2 reload
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
#### Modificaciones en DNS y certificados
|
|
|
|
|
| ... | ... | @@ -143,9 +222,20 @@ service apache2 restart |
|
|
|
service tomcat restart
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Operaciones sobre el LDAP
|
|
|
|
|
|
|
|
* Junto a la migración del PWM, se incorporarán nuevos grupos al LDAP, así como nuevos miembros a los mismos.
|
|
|
|
* Para realizar estas operaciones, en el servidor OpenLDAP de producción (`ldap.interior.edu.uy`), se debe ejecutar el script de administración general del LDAP así: `./Admin_LDAP.sh`
|
|
|
|
* En primer lugar creamos el nuevo grupo `matrix_externos`. Para esto, elegimos la opción *4*, indicamos nombre de grupo y listo.
|
|
|
|
* A este nuevo grupo y al grupo `gitlab` se incorporará la **totalidad** de los usuarios existentes registrados en nuestro LDAP. Para efecutar la primera incorporación automática de estos usuarios, elegimos la opción *11*, indicamos nombre de grupo (una vez con `matrix_externos` y otra por `gitlab`) e ingresamos *all*.
|
|
|
|
* Por otro lado, agregaremos al grupo `eduroam` a todos los usuarios registrados con cuentas de mails de dominios **pertenecientes** a la UdelaR. Para esto, elegimos la opción *11*, indicamos nombre de grupo (`eduroam`) e ingresamos *udelar*.
|
|
|
|
* Por último, agregaremos al grupo `matrix` a todos los usuarios registrados con cuentas de mails de dominios **pertenecientes** a la Red de Unidades Informáticas del Interior. Para esto, elegimos la opción *11*, indicamos nombre de grupo (`matrix`) e ingresamos *interior*.
|
|
|
|
|
|
|
|
#### Pasos finales
|
|
|
|
|
|
|
|
* Ajustes en host_vars de `chalchal` para reflejar el final de la migración. Concretamente, activamos los dominios `identidad.interior.edu.uy, www.identidad.interior.edu.uy, identidad.interior.udelar.edu.uy, www.identidad.interior.udelar.edu.uy` en la conifugración de Certbot.
|
|
|
|
* Ajustes en host_vars de `chalchal` para reflejar el final de la migración.
|
|
|
|
* En la conifugración de Certbot activamos los dominios `identidad.interior.edu.uy, www.identidad.interior.edu.uy, identidad.interior.udelar.edu.uy, www.identidad.interior.udelar.edu.uy`.
|
|
|
|
* Indicamos en las variables de PWM que se está conectando al LDAP de producción: `ldap.interior.edu.uy`.
|
|
|
|
|
|
|
|
* Al día siguiente detenemos el servicio Tomcat en `varela`, Apache seguirá encendido. `Varela` no se apaga esta vez, recién se detendrá una vez migrada la agenda telefónica hacia otro contenedor de la nueva plataforma.
|
|
|
|
|
| ... | ... | |
| ... | ... | |
