| ... | ... | @@ -34,7 +34,7 @@ En caso de que no se logre un merge automático, será necesario resolver los co |
|
|
|
Primero se configuran las host vars de Candombe. Concretamente, se creo un nuevo directorio en host_vars/candombe.interior.edu.uy y se definieron y ajustaron variables en vars y vaults de la siguiente manera:
|
|
|
|
* Parámetros de configuración del LXC (vars/10_lxc_container.yml). Le damos 8 GB de RAM, 4 GB de Swap y le definimos un disco de 2GB sobre el volúmen NFS nubes.
|
|
|
|
Parámetros de configuración del Nextcloud (vars/40_nextcloud.yml).
|
|
|
|
* **nextcloud_version_major** y **nextcloud_db_backend**. Se configuran estos valores para instalar un NC 10, con conexión a base Postgres. Partimos de esta versión porque queremos ir hacia un NextCloud y tenemos en nube.interior un Owncloud 9.1. Por más información, leer "este enlace":https://nextcloud.com/migration/.
|
|
|
|
* **nextcloud_version_major** y **nextcloud_db_backend**. Se configuran estos valores para instalar un NC 10, con conexión a base Postgres. Partimos de esta versión porque queremos ir hacia un NextCloud y tenemos en nube.interior un Owncloud 9.1. Por más información, leer [este enlace](https://nextcloud.com/migration/).
|
|
|
|
* **nextcloud_db_admin**. En Halley, el usuario Postgres que usa Owncloud para conectarse a la base es oc2016. Por esa razón y para simplificar la migración de la base de datos, definimos el mismo usuario en Candombe. De esta manera, se creará ese usuario en Postgres que permitirá que el Nextcloud se conecte a la base de datos.
|
|
|
|
* **nextcloud_config_settings**. Debido a que estamos realizando una tarea de migración, algunos parámetros de configuración de la vieja instalación deben mantenerse como con sus valores originales como: instanceid, passwordsalt y secret. Además se incorporarán a la configuración parámetros inherentes a la vieja instalación que el rol por defecto no define. También se descartará el parámetro mysql.utf8mb4 ya que se trabajará con una base Postgres.
|
|
|
|
* Certbot (vars/30_certbot.yml)
|
| ... | ... | @@ -50,12 +50,13 @@ Se crea el contenedor y se instala el NC mediante el rol de la galaxia de nuestr |
|
|
|
|
|
|
|
`ansible-playbook site.yml --limit candombe.interior.edu.uy -i host_prod`
|
|
|
|
|
|
|
|
Algunos detalles
|
|
|
|
## Algunos detalles
|
|
|
|
|
|
|
|
Luego de haber instalado el servidor, debido a que el rol deja activado el virtualhost por defecto de Apache (000-default.conf), la primera vez que accedemos por el navegador vamos a ver la página de Apache.
|
|
|
|
|
|
|
|
Además, a nivel de consola, por algún otro detalle, vemos estos mensajes:
|
|
|
|
|
|
|
|
```
|
|
|
|
root@candombe:~# service apache2 status
|
|
|
|
● apache2.service - The Apache HTTP Server
|
|
|
|
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
|
| ... | ... | @@ -78,168 +79,191 @@ dic 12 20:32:06 candombe systemd[1]: apache2.service: Failed to reset devices.li |
|
|
|
dic 12 20:32:17 candombe systemd[1]: apache2.service: Failed to reset devices.list: Operation not permitted
|
|
|
|
dic 12 20:32:20 candombe systemd[1]: apache2.service: Failed to reset devices.list: Operation not permitted
|
|
|
|
dic 12 20:33:23 candombe systemd[1]: apache2.service: Failed to reset devices.list: Operation not permitted
|
|
|
|
|
|
|
|
```
|
|
|
|
Estos problemas se solucionan desactivando el virtualhost por defecto y reiniciando Apache:
|
|
|
|
|
|
|
|
```
|
|
|
|
a2dissite 000-default.conf
|
|
|
|
service apache2 restart
|
|
|
|
Configurar Firewall perimetral
|
|
|
|
```
|
|
|
|
|
|
|
|
## Configurar Firewall perimetral
|
|
|
|
|
|
|
|
Desde el navegador accedemos a la interfaz gráfica del Firewall Mikrotick de la nueva plataforma en http://chinchulin.interior.edu.uy.
|
|
|
|
|
|
|
|
Vamos IP, Firewall, Adress Lists y agreamos una entrada para la lista de direcciones "web" correspondientes al nombre de dominio de Candombe (candombe.interior.edu.uy). De esta manera quedarán abiertos los puertos 80 y 443 para Candombe a traves de Chinchulin.
|
|
|
|
|
|
|
|
Detener servicios en Candonmbe
|
|
|
|
## Detener servicios en Candonmbe
|
|
|
|
|
|
|
|
Poner el Nextcloud en mantenimiento y detener el servicio web (Apache):
|
|
|
|
|
|
|
|
```
|
|
|
|
cd /opt/nextcloud
|
|
|
|
sudo -u www-data php occ maintenance:mode --on
|
|
|
|
service apache2 stop
|
|
|
|
```
|
|
|
|
|
|
|
|
Preparar directorios y archivos en Candombe
|
|
|
|
## Preparar directorios y archivos en Candombe
|
|
|
|
|
|
|
|
Para la restauración de los datos desde los respaldos, es necesario borrar el contenido del directorio ncdata:
|
|
|
|
|
|
|
|
```
|
|
|
|
cd /var/ncdata
|
|
|
|
rm -R *
|
|
|
|
```
|
|
|
|
|
|
|
|
## Primera restauración de archivos
|
|
|
|
|
|
|
|
Primera restauración de archivos
|
|
|
|
En D'alembert desde la interfaz web de Backuppc se configura el respaldo de Candombe, siguiendo [este procedimiento](https://proyectos.interior.edu.uy/projects/respaldos/wiki/Procedimiento_para_agregar_un_servidor_a_los_respaldos#Agregar-un-servidor-manualmente-al-servidor-dalembert). Concretamente:
|
|
|
|
|
|
|
|
En D'alembert desde la interfaz web de Backuppc se configura el respaldo de Candombe, siguiendo este procedimiento:
|
|
|
|
https://proyectos.interior.edu.uy/projects/respaldos/wiki/Procedimiento_para_agregar_un_servidor_a_los_respaldos#Agregar-un-servidor-manualmente-al-servidor-dalembert. Concretamente:
|
|
|
|
* Se agrega el host candombe.interior.edu.uy
|
|
|
|
* Desde Candombe le defino una password a mi usuario apias.
|
|
|
|
* Desde D'alembert como backuppc:
|
|
|
|
|
|
|
|
Se agrega el host candombe.interior.edu.uy
|
|
|
|
Desde Candombe le defino una password a mi usuario apias.
|
|
|
|
Desde D'alembert como backuppc: ssh-copy-id apias@candombe.interior.edu.uy
|
|
|
|
En Candombe, le copio al usuario root la clave subida anteriormente
|
|
|
|
cat /home/apias/.ssh/authorized_keys | grep backuppc >> /root/.ssh/authorized_keys
|
|
|
|
Probamos para ver si funciona: $ ssh -q -x -l root candombe.interior.edu.uy
|
|
|
|
`ssh-copy-id apias@candombe.interior.edu.uy`
|
|
|
|
|
|
|
|
Luego, desde esta misma interfaz, se proceden a restaurar en Candombe los siguientes directorios y archivos desde el último respaldo de Halley:
|
|
|
|
* En Candombe, le copio al usuario root la clave subida anteriormente:
|
|
|
|
|
|
|
|
/var/www/owncloud/data/* -> /var/ncdata
|
|
|
|
`cat /home/apias/.ssh/authorized_keys | grep backuppc >> /root/.ssh/authorized_keys`
|
|
|
|
|
|
|
|
* Probamos para ver si funciona: $ ssh -q -x -l root candombe.interior.edu.uy
|
|
|
|
|
|
|
|
Esta primera restauración dura 2 días. Seguramente con esta primera copia de datos no se consiga restaurar la totalidad de datos que actualmente posee la nube en producción, sin embargo, se consigue que las subsiguientes copias demoren menos.
|
|
|
|
Luego, desde esta misma interfaz, se proceden a restaurar en Candombe los siguientes directorios y archivos desde el **último respaldo** de Halley:
|
|
|
|
|
|
|
|
> /var/www/owncloud/data/* -> /var/ncdata
|
|
|
|
|
|
|
|
Esta primera restauración dura **2 días**. Seguramente con esta primera copia de datos no se consiga restaurar la totalidad de datos que actualmente posee la nube en producción, sin embargo, se consigue que las subsiguientes copias demoren menos.
|
|
|
|
|
|
|
|
Establecer acceso remotos entre servidores
|
|
|
|
## Establecer acceso remotos entre servidores
|
|
|
|
|
|
|
|
Para que sea posible la copia de datos entre servidores es necesario definir acceso con clave pública y privada desde Halley a Candombe. Para eso hacemos lo siguiente:
|
|
|
|
|
|
|
|
En Halley como root genero un clave pública/privada:
|
|
|
|
ssh-keygen -b 8192
|
|
|
|
Desde ahí mismo como root copiamos la clave a Candombe.
|
|
|
|
ssh-copy-id apias@candombe.interior.edu.uy
|
|
|
|
En Candombe, le copio al usuario root la clave subida anteriormente
|
|
|
|
cat /home/apias/.ssh/authorized_keys | grep root@halley >> /root/.ssh/authorized_keys
|
|
|
|
Finalmente verificamos el acceso entre servidores de root a root.
|
|
|
|
* En Halley como root genero un clave pública/privada:
|
|
|
|
|
|
|
|
`ssh-keygen -b 8192`
|
|
|
|
* Desde ahí mismo como root copiamos la clave a Candombe.
|
|
|
|
|
|
|
|
`ssh-copy-id apias@candombe.interior.edu.uy`
|
|
|
|
* En Candombe, le copio al usuario root la clave subida anteriormente
|
|
|
|
|
|
|
|
`cat /home/apias/.ssh/authorized_keys | grep root@halley >> /root/.ssh/authorized_keys`
|
|
|
|
* Finalmente verificamos el acceso entre servidores de root a root.
|
|
|
|
|
|
|
|
Envío de comunicados a los usuarios
|
|
|
|
## Envío de comunicados a los usuarios
|
|
|
|
|
|
|
|
Previo al día de la migración avisar a los usuarios que existirá no disponibilidad del servicio por un tiempo de 2 horas. Se manda un comunicado a la lista nubeinterior@listas.softwarelibre.edu.uy que se encuentra actualizada. Bien podemos hacer una nueva lista.
|
|
|
|
|
|
|
|
TRABAJO DEL MOMENTO DE MIGRACIÓN
|
|
|
|
# TRABAJO DEL MOMENTO DE MIGRACIÓN
|
|
|
|
|
|
|
|
Segunda restauración de archivos
|
|
|
|
## Segunda restauración de archivos
|
|
|
|
|
|
|
|
Se hace una copia de archivos en caliente desde Halley a Candombe:
|
|
|
|
|
|
|
|
rsync -arvz --progress --delete /var/www/owncloud/data/ root@candombe.interior.edu.uy:/var/ncdata
|
|
|
|
`rsync -arvz --progress --delete /var/www/owncloud/data/ root@candombe.interior.edu.uy:/var/ncdata`
|
|
|
|
|
|
|
|
Esta sincronización no va a durar más de 1h 30 min. Depende de la distancia que exista entre su realización y la restauración anterior.
|
|
|
|
|
|
|
|
Luego conviene revisar que el tamaño ocupado en disco por el directorio de origen (var/www/owncloud/data/) coincida con el del directorio de destino (var/ncdata):
|
|
|
|
|
|
|
|
```
|
|
|
|
root@candombe:/var# du -csh ncdata
|
|
|
|
439G ncdata
|
|
|
|
439G total
|
|
|
|
```
|
|
|
|
|
|
|
|
Detención de servicios en Halley y respaldo de la base de datos
|
|
|
|
## Detención de servicios en Halley y respaldo de la base de datos
|
|
|
|
|
|
|
|
Se detienen los servicios en Halley:
|
|
|
|
|
|
|
|
```
|
|
|
|
cd /var/www/owncloud
|
|
|
|
sudo -u www-data php occ maintenance:mode --on
|
|
|
|
service apache2 stop
|
|
|
|
```
|
|
|
|
|
|
|
|
De forma manual se genera un respaldo actual de la base de datos:
|
|
|
|
|
|
|
|
sudo -u postgres pg_dump owncloud-interior > /var/backups/pgsql/postgres_dump_owncloud_XX.sql
|
|
|
|
`sudo -u postgres pg_dump owncloud-interior > /var/backups/pgsql/postgres_dump_owncloud_XX.sql`
|
|
|
|
|
|
|
|
Se copia este respaldo a Candombe:
|
|
|
|
|
|
|
|
scp /var/backups/pgsql/postgres_dump_owncloud_XX.sql root@candombe.interior.edu.uy:/root/
|
|
|
|
|
|
|
|
`scp /var/backups/pgsql/postgres_dump_owncloud_XX.sql root@candombe.interior.edu.uy:/root/ `
|
|
|
|
|
|
|
|
|
|
|
|
Tercera restauración de archivos
|
|
|
|
## Tercera restauración de archivos
|
|
|
|
|
|
|
|
Se hace un rsync en frío de los mismos archivos:
|
|
|
|
|
|
|
|
rsync -arvz --progress --delete /var/www/owncloud/data/ root@candombe.interior.edu.uy:/var/ncdata
|
|
|
|
`rsync -arvz --progress --delete /var/www/owncloud/data/ root@candombe.interior.edu.uy:/var/ncdata`
|
|
|
|
|
|
|
|
Esta última sincronización debería demorar muy poco (aproximadamente 6 minutos).
|
|
|
|
|
|
|
|
Restauración de la base de datos
|
|
|
|
## Restauración de la base de datos
|
|
|
|
|
|
|
|
Volvemos a Candombe. Con el usuario root se reubica el dump de la base de datos:
|
|
|
|
|
|
|
|
```
|
|
|
|
cp /root/postgres_dump_owncloud_XX.sql /var/lib/postgresql/
|
|
|
|
chown postgres:postgres /var/lib/postgresql/postgres_dump_owncloud_XX.sql
|
|
|
|
```
|
|
|
|
|
|
|
|
El role Nextcloud nos creó en Postgres una base de datos nextcloud y un role oc2016. La base de datos creada no nos sirve, la borramos y creamos una nueva vacía e importamos allí los datos:
|
|
|
|
El role Nextcloud nos creó en Postgres una base de datos **nextcloud** y un role **oc2016**. La base de datos creada no nos sirve, la borramos y creamos una nueva vacía e importamos allí los datos:
|
|
|
|
|
|
|
|
```
|
|
|
|
su - postgres
|
|
|
|
dropdb nextcloud
|
|
|
|
createdb --encoding=UNICODE --owner=oc2016 nextcloud
|
|
|
|
psql nextcloud < postgres_dump_owncloud_XX.sql
|
|
|
|
```
|
|
|
|
|
|
|
|
Ajustes en la configuración
|
|
|
|
Para mejorar la configuración, el rol de Postgres que definimos para instalar Nextcloud (oc2016) será renombrado por ncadmin que resulta más acorde a la nueva instalación. Entonces, se ejecuta un alterrole para cambiar el role oc2016 por ncadmin y para definirle la misma password que está almacenada en los vaults.
|
|
|
|
## Ajustes en la configuración
|
|
|
|
|
|
|
|
Para mejorar la configuración, el rol de Postgres que definimos para instalar Nextcloud (oc2016) será renombrado por **ncadmin** que resulta más acorde a la nueva instalación. Entonces, se ejecuta un alterrole para cambiar el role oc2016 por ncadmin y para definirle la misma password que está almacenada en los vaults:
|
|
|
|
|
|
|
|
```
|
|
|
|
psql nextcloud;
|
|
|
|
SELECT rolname FROM pg_roles;
|
|
|
|
|
|
|
|
ALTER ROLE oc2016 RENAME TO ncadmin;
|
|
|
|
ALTER ROLE ncadmin WITH password '*claveVaults*';
|
|
|
|
```
|
|
|
|
|
|
|
|
Se edita el archivo de configuración config.php para indicar que el dbuser ahora es ncadmin.
|
|
|
|
Se edita el archivo de configuración config.php para indicar que el dbuser ahora es **ncadmin**.
|
|
|
|
|
|
|
|
Además, es necesario modificar las host vars de Candombe para que este sea efectivamente respaldado. Concretamente se modifico la variable nextcloud_db_admin en 40_nextcloud.yml:
|
|
|
|
|
|
|
|
```
|
|
|
|
#nextcloud_db_admin: "oc2016"
|
|
|
|
nextcloud_db_admin: "ncadmin"
|
|
|
|
```
|
|
|
|
|
|
|
|
Luego lanzamos el playbook para reconfigurar respaldos:
|
|
|
|
|
|
|
|
ansible-playbook site.yml --limit candombe.interior.edu.uy --tags backuppc_client -i host_prod
|
|
|
|
`ansible-playbook site.yml --limit candombe.interior.edu.uy --tags backuppc_client -i host_prod`
|
|
|
|
|
|
|
|
Se prueba hacer un primer respaldo y se verifica que no surjan errores.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Encender servicios en Candombe
|
|
|
|
## Encender servicios en Candombe
|
|
|
|
|
|
|
|
Levantar Apache y desactivar el modo mantenimiento de Nextcloud:
|
|
|
|
|
|
|
|
```
|
|
|
|
cd /opt/nextcloud
|
|
|
|
service apache2 start
|
|
|
|
sudo -u www-data php occ maintenance:mode --off
|
|
|
|
```
|
|
|
|
|
|
|
|
Actualización inicial de la base de datos (Upgrade)
|
|
|
|
## Actualización inicial de la base de datos (Upgrade)
|
|
|
|
|
|
|
|
Finalmente ejecutamos la herramienta occ de línea de comandos para ejecutar el upgrade de la base de datos:
|
|
|
|
|
|
|
|
```
|
|
|
|
sudo -u www-data php occ upgrade.
|
|
|
|
sudo -u www-data php occ maintenance:mode --off
|
|
|
|
```
|
|
|
|
|
|
|
|
Logramos poner en marcha el Nextcloud en https://candombe.interior.edu.uy/
|
|
|
|
Verificación de las actualizaciones
|
|
|
|
|
|
|
|
## Verificación de las actualizaciones
|
|
|
|
|
|
|
|
Luego de cada actualización conviene realizar una serie de chequeos para verificar que la instalación haya quedado correcta y que todo funcione de la forma esperada. Por ejemplo:
|
|
|
|
|
|
|
|
1. Desde la interfaz web vamos a Administración y de forma automática se hace un chequeo de integridad cuyo resultado puede mostrar algún problema de inconsistencias que debe ser resuelto.
|
| ... | ... | @@ -248,29 +272,32 @@ Luego de cada actualización conviene realizar una serie de chequeos para verifi |
|
|
|
|
|
|
|
3. También puede ser útil chequear que las aplicaciones disponibles/activadas no hayan "cambiado". Para verificar si ocurrió algún problema puntual con una aplicación, se puede hacer click en el botón "+" (que permite agregar aplicaciones) y a medida que se scrollea se puede ver si se presentó algún conflicto/incompatibilidad con alguna aplicación o si alguna de ellas quedó desactivada. En caso de que una aplicación que teníamos activada, aparezca al momento desactivada, se podría intentar actualizarla para volverla a activar.
|
|
|
|
|
|
|
|
Resolución de problemas
|
|
|
|
## Resolución de problemas
|
|
|
|
|
|
|
|
Luego de la migración aparecieron algunos errores en la página de Registro que fueron corregidos. Para conocer cuales son los problemas a resolver conviene obtenerlos desde consola de la siguiente manera:
|
|
|
|
|
|
|
|
```
|
|
|
|
cat nextcloud.log | grep '"level":3' | less
|
|
|
|
cat nextcloud.log | grep '"level":4' | less
|
|
|
|
```
|
|
|
|
|
|
|
|
Los errores encontrados y su solución se detallan a continuación:
|
|
|
|
|
|
|
|
Problema1: htaccess
|
|
|
|
### Problema1: htaccess
|
|
|
|
|
|
|
|
..."file_put_contents(\/var\/ncdata\/.htaccess): failed to open stream: Permission denied..
|
|
|
|
> ..."file_put_contents(\/var\/ncdata\/.htaccess): failed to open stream: Permission denied..
|
|
|
|
|
|
|
|
Al parecer Owncloud no tiene permisos para acceder al archivo htaccess que fue copiado desde Halley. Esto se solucionó modificando los permisos del archivo htaccess de esta manera:
|
|
|
|
|
|
|
|
chown www-data .htaccess
|
|
|
|
`chown www-data .htaccess`
|
|
|
|
|
|
|
|
Problema2: LDAP
|
|
|
|
### Problema2: LDAP
|
|
|
|
|
|
|
|
..."dc0b86d6-620b-1034-87a0-4d5fcc5b2e44 is not a valid user anymore\ "app":"no app in context"...
|
|
|
|
> ..."dc0b86d6-620b-1034-87a0-4d5fcc5b2e44 is not a valid user anymore\ "app":"no app in context"...
|
|
|
|
|
|
|
|
Este es un error que ya se registraba de la antigua instalación. El directorio en cuestión (dc0b86d6-620b-1034-87a0-4d5fcc5b2e44) corresponde con el usuario del LDAP pgarcia. Sin embargo, en el LDAP, el cn de pgarcia cambió a pablo.garcia. A partir de ese momento se empezó a registrar este reiterado problema en los logs. Todo es puede ser verificado desde la base de datos:
|
|
|
|
Este es un error que ya se registraba de la antigua instalación. El directorio en cuestión (*dc0b86d6-620b-1034-87a0-4d5fcc5b2e44*) corresponde con el usuario del LDAP *pgarcia*. Sin embargo, en el LDAP, el cn de pgarcia cambió a pablo.garcia. A partir de ese momento se empezó a registrar este reiterado problema en los logs. Todo es puede ser verificado desde la base de datos:
|
|
|
|
|
|
|
|
```
|
|
|
|
postgres@candombe:~$ psql nextcloud
|
|
|
|
nextcloud=# select * from oc_ldap_user_mapping where owncloud_name='dc0b86d6-620b-1034-87a0-4d5fcc5b2e44';
|
|
|
|
ldap_dn | owncloud_name | directory_uuid
|
| ... | ... | @@ -283,174 +310,188 @@ nextcloud=# select * from oc_ldap_user_mapping where ldap_dn='cn=pablo.garcia,ou |
|
|
|
-------------------------------------------------+--------------------------------------+--------------------------------------
|
|
|
|
cn=pablo.garcia,ou=gente,dc=udelar,dc=edu,dc=uy | 344afce6-6481-1035-84d3-21cb291cba22 | 344afce6-6481-1035-84d3-21cb291cba22
|
|
|
|
(1 fila)
|
|
|
|
```
|
|
|
|
|
|
|
|
En este enlace https://docs.nextcloud.com/server/9.0/admin_manual/configuration_user/user_auth_ldap_cleanup.html se explica que en Owncloud/Nextcloud existe un proceso que chequa periódicamente si los usuarios a nivel del LDAP siguen disponibles. Si un usuario no está mas en el ldap lo marca como deleted:
|
|
|
|
En [este enlace](https://docs.nextcloud.com/server/9.0/admin_manual/configuration_user/user_auth_ldap_cleanup.html) se explica que en Owncloud/Nextcloud existe un proceso que chequa periódicamente si los usuarios a nivel del LDAP siguen disponibles. Si un usuario no está mas en el ldap lo marca como deleted.
|
|
|
|
|
|
|
|
Los usuarios que están marcados como eliminados se pueden ver de la siguiente manera:
|
|
|
|
|
|
|
|
root@candombe:/opt/nextcloud# sudo -u www-data php occ ldap:show-remnants | less
|
|
|
|
`root@candombe:/opt/nextcloud# sudo -u www-data php occ ldap:show-remnants | less`
|
|
|
|
|
|
|
|
Entre ellos está pgarcia:
|
|
|
|
```
|
|
|
|
....
|
|
|
|
| dc0b86d6-620b-1034-87a0-4d5fcc5b2e44 | pgarcia | | cn=pgarcia,ou=gente,dc=udelar,dc=edu,dc=uy
|
|
|
|
....
|
|
|
|
```
|
|
|
|
|
|
|
|
Para solucionar el problema y evitar recibir estos mensajes, se puede remover el usuario pgarcia del Owncloud junto con todos sus datos de la siguiente manera:
|
|
|
|
|
|
|
|
sudo -u www-data php occ user:delete dc0b86d6-620b-1034-87a0-4d5fcc5b2e44
|
|
|
|
`sudo -u www-data php occ user:delete dc0b86d6-620b-1034-87a0-4d5fcc5b2e44`
|
|
|
|
|
|
|
|
Problema3: Api Store
|
|
|
|
### Problema3: Api Store
|
|
|
|
|
|
|
|
"app":"core","message":"Could not get application: cURL error 6: Could not resolve host: api.owncloud.com"
|
|
|
|
> "app":"core","message":"Could not get application: cURL error 6: Could not resolve host: api.owncloud.com"
|
|
|
|
|
|
|
|
Este error se registra con menor frecuencia que el problema anterior. Este error fue tratado en "este hilo":https://github.com/owncloud/core/issues/30997 y tiene que ver con que el Ownclod desde el que partimos está desactualizado. Se solucionará al ir realizando las sucesivas actualizaciones.
|
|
|
|
Este error se registra con menor frecuencia que el problema anterior. Este error fue tratado en [este hilo](https://github.com/owncloud/core/issues/30997) y tiene que ver con que el Ownclod desde el que partimos está desactualizado. Se solucionará al ir realizando las sucesivas actualizaciones.
|
|
|
|
|
|
|
|
Actualizaciones del NextCloud
|
|
|
|
## Actualizaciones del NextCloud
|
|
|
|
|
|
|
|
En primer lugar será necesario eliminar el directorio assets para que la actualización funcione.
|
|
|
|
En primer lugar será necesario eliminar el directorio assets para que las actualizaciones funcionen:
|
|
|
|
|
|
|
|
root@candombe:/opt/nextcloud# rmdir assets
|
|
|
|
`root@candombe:/opt/nextcloud# rmdir assets`
|
|
|
|
|
|
|
|
Cabe aclarar que durante el proceso de actualización de forma automática se deshabilitarán y/o eliminarán aplicaciones obsoletas o incompatibles (de terceros) con NC como son, document, templateeditor, external, configreport, etc.
|
|
|
|
Cabe aclarar que durante el proceso de actualización de forma automática se deshabilitarán y/o eliminarán aplicaciones obsoletas o incompatibles (de terceros) con NC como son, **document**, **templateeditor**, **external**, **configreport**, etc.
|
|
|
|
|
|
|
|
Actualizamos de 10 a 11
|
|
|
|
### Actualizamos de 10 a 11
|
|
|
|
|
|
|
|
Debido a estar en versiones antiguas de owncloud, el proceso automático de descarga de la siguiente versión no funciona, problema tratada acá: https://help.nextcloud.com/t/migrating-owncloud-10-0-10-4-to-nextcloud-http-status-code-429/60248/2
|
|
|
|
Debido a estar en versiones antiguas de owncloud, el proceso automático de descarga de la siguiente versión no funciona (problema tratado [acá](https://help.nextcloud.com/t/migrating-owncloud-10-0-10-4-to-nextcloud-http-status-code-429/60248/2)).
|
|
|
|
|
|
|
|
Por esta razón, para lograr la actualización tenemos unos pasos manuales como los siguientes:
|
|
|
|
Por esta razón, para lograr la actualización tenemos que realizar los siguientes pasos manuales:
|
|
|
|
```
|
|
|
|
cd /var/ncdata/updater-{instanceid}/downloads/
|
|
|
|
wget https://download.nextcloud.com/server/releases/nextcloud-11.0.8.zip
|
|
|
|
chown www-data:www-data nextcloud-11.0.8.zip
|
|
|
|
```
|
|
|
|
|
|
|
|
Luego tenemos que editar el código del script de actualización ubicado en /opt/nextcloud/updater/index.php. Tenemos que comentar la llamada a la función de descarga downloadUpdate().
|
|
|
|
Además tenemos que editar el código del script de actualización ubicado en /opt/nextcloud/updater/index.php. Concretamente se debe comentar la llamada a la función de descarga *downloadUpdate(*).
|
|
|
|
|
|
|
|
Desde la interfaz web de candombe.interior.edu.uy, vamos a Administración, Versión para proceder con la actualización. Aquí nos indica cual es la siguiente versión a instalar, luego accedemos a la opción Abrir el actualizador (Updater) donde nos dice:
|
|
|
|
Luego desde la interfaz web de candombe.interior.edu.uy, vamos a Administración, Versión para proceder con la actualización. Aquí nos indica cual es la siguiente versión a instalar, luego accedemos a la opción Abrir el actualizador (Updater) donde nos dice:
|
|
|
|
|
|
|
|
```
|
|
|
|
Current version is 10.0.6.
|
|
|
|
Update to Nextcloud 11.0.8 available. (channel: "production")
|
|
|
|
Following file will be downloaded automatically: https://download.nextcloud.com/server/releases/nextcloud-11.0.8.zip
|
|
|
|
```
|
|
|
|
|
|
|
|
Le indicamos Start update y esperamos a que realice la actualización de forma automática.
|
|
|
|
|
|
|
|
Si sale todo bien, indicamos que deseamos mantener el modo de mantenimiento activo para finalizar el proceso de upgrade desde consola. Vamos a la consola y ejecutamos el siguiente comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
sudo -u www-data php occ -vvv upgrade
|
|
|
|
sudo -u www-data php occ maintenance:mode --off
|
|
|
|
```
|
|
|
|
|
|
|
|
Luego de cada actualización conviene hacer una serie de chequeos para verificar que todo funciona como se espera. Los chequeos a realizar están descriptos en la sección Verificación de las actualizaciones.
|
|
|
|
Luego de cada actualización conviene hacer una serie de chequeos para verificar que todo funciona como se espera. Los chequeos a realizar están descriptos en la sección **Verificación de las actualizaciones**.
|
|
|
|
|
|
|
|
Actualizamos de 11 a 12
|
|
|
|
### Actualizamos de 11 a 12
|
|
|
|
|
|
|
|
Se siguen los pasos presentados anteriormente. Nuevamente fue necesario descargar el zip de forma manual. En este caso la url es https://download.nextcloud.com/server/releases/nextcloud-12.0.13.zip. Luego de culminada la actualización, volvemos a realizar verificaciones.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Actualizamos de 12 a 13
|
|
|
|
### Actualizamos de 12 a 13
|
|
|
|
|
|
|
|
Se siguen los pasos presentados anteriormente. A partir de esta actualización ya no es necesario descargar el zip de forma manual, sino que el script de update logra completar todos los pasos de forma automática.
|
|
|
|
|
|
|
|
Por lo tanto, no se debería registrar ningún tipo de problema. Luego de culminada la actualización, volvemos a realizar verificaciones.
|
|
|
|
|
|
|
|
Actualizamos de 13 a 14
|
|
|
|
### Actualizamos de 13 a 14
|
|
|
|
|
|
|
|
En este este caso, luego de completar la actualización, la interfaz web (en Administración, Vista general) nos indica lo siguiente:
|
|
|
|
|
|
|
|
A la base de datos le faltan algunos índices. Debido al hecho de que añadir índices en tablas grandes puede llevar cierto tiempo, no se han añadido automáticamente. Se pueden añadir manualmente dichos índices perdidos mientras la instancia sigue funcionando si se ejecuta "occ db:add-missing-indices". Una vez se han añadido los índices, las consultas a esas tablas suelen ser mucho más rápidas.
|
|
|
|
|
|
|
|
> A la base de datos le faltan algunos índices. Debido al hecho de que añadir índices en tablas grandes puede llevar cierto tiempo, no se han añadido automáticamente. Se pueden añadir manualmente dichos índices perdidos mientras la instancia sigue funcionando si se ejecuta "occ db:add-missing-indices". Una vez se han añadido los índices, las consultas a esas tablas suelen ser mucho más rápidas.
|
|
|
|
|
|
|
|
##FALTA IMAGEN
|
|
|
|
|
|
|
|
Por lo tanto, desde la consola se lanza:
|
|
|
|
|
|
|
|
sudo -u www-data php occ -vvv db:add-missing-indices
|
|
|
|
`sudo -u www-data php occ -vvv db:add-missing-indices`
|
|
|
|
|
|
|
|
Paso final, volver a realizar verificaciones y chequeos.
|
|
|
|
Paso final, volver a realizar verificaciones y chequeos. Durante los chequeos, se observa en los logs el siguiente error:
|
|
|
|
|
|
|
|
Además aparece en los logs el siguiente error
|
|
|
|
|
|
|
|
Error PHP Undefined index: total at /opt/nextcloud/lib/private/Repair/RemoveLinkShares.php#130 2019-12-30T15:21:45-0300
|
|
|
|
`Error PHP Undefined index: total at /opt/nextcloud/lib/private/Repair/RemoveLinkShares.php#130 2019-12-30T15:21:45-0300`
|
|
|
|
|
|
|
|
En principio no se conoce el origen del error pero tiene que ver con una acción ejecutada para realizar reparaciones a nivel de base de datos. Dicha acción fue lanzada desde el momento de la actualización posiblemente.
|
|
|
|
|
|
|
|
{"reqId":"ZbLfOQf0RnTvJ08ITE5t","level":3,"time":"2019-12-30T18:21:45+00:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"Undefined index: total at \/opt\/nextcloud\/lib\/private\/Repair\/RemoveLinkShares.php#130","userAgent":"--","version":"13.0.12.1"}
|
|
|
|
|
|
|
|
Al no encontrar información al respecto del error, no entender como solucionarlo y al no haberse cortado la actualización se avanza con el siguiente paso.
|
|
|
|
Al no encontrar información al respecto del error, no entender como solucionarlo y al no haberse detenido el proceso de actualización se avanza con el siguiente paso.
|
|
|
|
|
|
|
|
Actualizamos de 14 a 15
|
|
|
|
### Actualizamos de 14 a 15
|
|
|
|
|
|
|
|
Se realiza esta actualización siguiendo los pasos presentados anteriormente. Al momento de hacer el upgrade desde consola comprobamos que la parte de Remove Links Shares no presentara inconvenientes:
|
|
|
|
Se realiza esta actualización siguiendo los pasos presentados anteriormente. Al momento de hacer el upgrade desde consola comprobamos que la parte de Remove Links Shares no presenta inconvenientes:
|
|
|
|
|
|
|
|
```
|
|
|
|
2019-12-30T19:04:04+00:00 Repair step: Remove potentially over exposing share links
|
|
|
|
2019-12-30T19:04:04+00:00 Repair info: No need to remove link shares.
|
|
|
|
```
|
|
|
|
|
|
|
|
En la interfaz web aparecen las siguientes advertencias a ser corregidas:
|
|
|
|
|
|
|
|
|
|
|
|
## FALTA IMAGEN
|
|
|
|
|
|
|
|
Esto lleva a ejecutar lo siguiente de forma manual:
|
|
|
|
|
|
|
|
```
|
|
|
|
sudo -u www-data php occ -vvv db:add-missing-indices
|
|
|
|
sudo -u www-data php occ -vvv db:convert-filecache-bigint
|
|
|
|
```
|
|
|
|
|
|
|
|
Esto último demoró unos minutos pero no fue mucho. Luego de realizar esta penúltima actualización aparecerá una única advertencia indicando que las nuevas versiones de Nextcloud requerirían versiones de PHP superiores a la 7.0.3 que tiene el servidor instalado.
|
|
|
|
|
|
|
|
Post-actualización.
|
|
|
|
## Post-actualización.
|
|
|
|
|
|
|
|
Como paso final, se vuelven a instalar y activar algunas aplicaciones.
|
|
|
|
|
|
|
|
Se podrá ver que la aplicación External sites requiere actualizaciones para que pueda ser nuevamente activada. En este caso particular, conviene eliminar dicha aplicación para luego instalarla en su versión más reciente.
|
|
|
|
Se podrá ver que la aplicación **External sites** requiere actualizaciones para que pueda ser nuevamente activada. En este caso particular, conviene eliminar dicha aplicación para luego instalarla en su versión más reciente.
|
|
|
|
|
|
|
|
Luego se vuelven a instalar y activar algunas otras aplicaciones que consideremos necesarias que pueden haberse desactivado debido a las sucesivas actualizaciones del Nextcloud. Concretamente instalamos, actualizamos y activamos las aplicaciones: Calendar y Contact.
|
|
|
|
Luego se vuelven a instalar y activar algunas otras aplicaciones que consideremos necesarias que pueden haberse desactivado debido a las sucesivas actualizaciones del Nextcloud. Concretamente instalamos, actualizamos y activamos las aplicaciones: **Calendar** y **Contact**.
|
|
|
|
|
|
|
|
Merece aclarar que la aplicación Document ha sido descontinuada desde Owncloud 10 y por lo tanto no puede ser instalada por no estar disponible en la tienda. Esta es una aplicación No Oficial que tuvimos alguna vez activada en la nube en producción, que ofrecía una edición muy básica online y colaborativa de documentos de texto. Los reemplazos a esta aplicación son https://marketplace.owncloud.com/apps/richdocuments y https://www.collaboraoffice.com/code/
|
|
|
|
Merece aclarar que la aplicación **Document** ha sido descontinuada desde Owncloud 10 y por lo tanto no puede ser instalada por no estar disponible en la tienda. Esta es una aplicación No Oficial que tuvimos alguna vez activada en la nube en producción, que ofrecía una edición muy básica online y colaborativa de documentos de texto. Los reemplazos a esta aplicación son https://marketplace.owncloud.com/apps/richdocuments y https://www.collaboraoffice.com/code/
|
|
|
|
|
|
|
|
Modificación de la presentación del servicio.
|
|
|
|
## Modificación de la presentación del servicio
|
|
|
|
|
|
|
|
Finalmente se modifica el aspecto de la interfaz gráfica del Nexcloud desde la administración para que quede con el aspecto Udelar. Concretamente:
|
|
|
|
Se subió el logo
|
|
|
|
Se dejó un fondo común sólido.
|
|
|
|
Se cambian enunciados del footer y el header.
|
|
|
|
* Se subió el logo.
|
|
|
|
* Se dejó un fondo común sólido.
|
|
|
|
* Se cambian enunciados del footer y el header.
|
|
|
|
|
|
|
|
Modificación de la zona interior.edu.uy
|
|
|
|
## Modificación de la zona interior.edu.uy
|
|
|
|
|
|
|
|
Para actualizar la zona nos basamos en el procedimiento:
|
|
|
|
https://proyectos.interior.edu.uy/projects/dns/wiki/Manejo_de_zonas_con_ansible
|
|
|
|
Para actualizar la zona nos basamos en [este procedimiento](https://proyectos.interior.edu.uy/projects/dns/wiki/Manejo_de_zonas_con_ansible).
|
|
|
|
|
|
|
|
Nos paramos en la rama master de la siguiente forma y la actualizamos:
|
|
|
|
Nos paramos en la rama master de la siguiente forma y **la actualizamos**:
|
|
|
|
|
|
|
|
```
|
|
|
|
git checkout master
|
|
|
|
git pull
|
|
|
|
```
|
|
|
|
|
|
|
|
El archivo de zona interior.edu.uy se actualiza con los siguientes cambios:
|
|
|
|
agregamos un comentario indicando que Candombe es la nube en producción.
|
|
|
|
se modifica el alias nube.interior.edu.uy
|
|
|
|
se actualiza el serial
|
|
|
|
* agregamos un comentario indicando que Candombe es la nube en producción.
|
|
|
|
* se modifica el alias nube.interior.edu.uy
|
|
|
|
* se actualiza el serial
|
|
|
|
|
|
|
|
Luego lanzamos el playbook:
|
|
|
|
|
|
|
|
ansible-playbook -i hosts_prod --limit guabiyu.interior.edu.uy site.yml -vv --tags ns_master
|
|
|
|
`ansible-playbook -i hosts_prod --limit guabiyu.interior.edu.uy site.yml -vv --tags ns_master`
|
|
|
|
|
|
|
|
Se suben los cambios al repositorio central:
|
|
|
|
|
|
|
|
```
|
|
|
|
git add -A
|
|
|
|
git commit
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
|
|
|
|
Generación de nuevos certificados
|
|
|
|
## Generación de nuevos certificados
|
|
|
|
|
|
|
|
Ahora que esta instalación quedó en funcionamiento en producción en nube.interior.edu.uy, se deben volver a generar los certificados HTTPS para incluir los correspondientes a dicho dominio. Este paso se realiza de forma manual desde el servidor:
|
|
|
|
Ahora que esta instalación quedó en funcionamiento en producción en nube.interior.edu.uy, se debe volver a generar el certificado HTTPS incluyendo a dicho dominio. Este paso se realiza de forma manual desde el servidor:
|
|
|
|
|
|
|
|
certbot certonly --standalone --noninteractive --agree-tos --email adminsys@cci.edu.uy --expand -d candombe.interior.edu.uy,nube.interior.edu.uy
|
|
|
|
`certbot certonly --standalone --noninteractive --agree-tos --email adminsys@cci.edu.uy --expand -d candombe.interior.edu.uy,nube.interior.edu.uy`
|
|
|
|
|
|
|
|
Por esta misma razón, se deberá editar el archivo config.php para indicar que el dominio principal que atiende la nube es nube.interior.edu.uy. Es decir concretamente, cambiamos esto:
|
|
|
|
|
|
|
|
```
|
|
|
|
array (
|
|
|
|
0 => 'candombe.interior.edu.uy',
|
|
|
|
1 => '164.73.98.70',
|
|
|
|
2 => '[2001:1328:6a::70]',
|
|
|
|
),
|
|
|
|
'overwrite.cli.url' => 'https://candombe.interior.edu.uy',
|
|
|
|
```
|
|
|
|
|
|
|
|
Por esto:
|
|
|
|
|
|
|
|
```
|
|
|
|
array (
|
|
|
|
0 => 'nube.interior.edu.uy',
|
|
|
|
1 => 'candombe.interior.edu.uy',
|
| ... | ... | @@ -458,29 +499,34 @@ Por esto: |
|
|
|
3 => '[2001:1328:6a::70]',
|
|
|
|
),
|
|
|
|
'overwrite.cli.url' => 'https://nube.interior.edu.uy',
|
|
|
|
```
|
|
|
|
|
|
|
|
TRABAJO POST MIGRACIÓN
|
|
|
|
# TRABAJO POST MIGRACIÓN
|
|
|
|
|
|
|
|
Merge en master
|
|
|
|
## Merge en master
|
|
|
|
|
|
|
|
Para finalizar, los cambios realizados se deben commitear a nivel de la rama de trabajo para luego sincronizarlos con el repositorio central.
|
|
|
|
|
|
|
|
```
|
|
|
|
git checkout 41
|
|
|
|
git pull
|
|
|
|
git add -A
|
|
|
|
git commit -a -m "finalizando la migración de nube.interior.edu.uy"
|
|
|
|
```
|
|
|
|
|
|
|
|
Una vez chequeado el buen funcionamiento de la nube en producción, se debe incorporar el trabajo hecho a la rama master, para eso creamos una Merge request desde la interfaz gráfica del gitlab. Para resolver esa Merge request concretamente haremos lo siguiente:
|
|
|
|
|
|
|
|
```
|
|
|
|
git checkout master
|
|
|
|
git pull
|
|
|
|
git checkout 41
|
|
|
|
git pull
|
|
|
|
git merge master
|
|
|
|
```
|
|
|
|
|
|
|
|
Enlaces
|
|
|
|
# Enlaces
|
|
|
|
|
|
|
|
https://proyectos.interior.edu.uy/issues/6042
|
|
|
|
https://nextcloud.com/migration/
|
|
|
|
https://docs.nextcloud.com/server/16/admin_manual/maintenance/manual_upgrade.html
|
|
|
|
https://proyectos.interior.edu.uy/projects/nube/wiki/Reconstrucci%C3%B3n_y_Upgrade_de_OwnCloud_desde_repositorios_ |
|
|
\ No newline at end of file |
|
|
|
* https://proyectos.interior.edu.uy/issues/6042
|
|
|
|
* https://nextcloud.com/migration/
|
|
|
|
* https://docs.nextcloud.com/server/16/admin_manual/maintenance/manual_upgrade.html
|
|
|
|
* https://proyectos.interior.edu.uy/projects/nube/wiki/Reconstrucci%C3%B3n_y_Upgrade_de_OwnCloud_desde_repositorios_ |
