Tareas #1546
Actualizar migasfree 4.15 to 4.16
0%
#1
Actualizado por Nacho Sancho hace más de 5 años
Actualizado por Hacer upgrade de migasfree-launcher en cliente?
#2
Actualizado por Nacho Sancho hace más de 5 años
- Actualización de las imágenes de migasfree, teniendo en cuenta los commits producidos en la versión base: https://github.com/migasfree/migasfree-docker/commits/master
- Test de la nueva versión en local
- Generación de los nuevos contenedores para vitlainux con la versión 4.16
- Upgrade en producción de las imágenes (fichero .env suficiente)
- Test en producción
- Upgrade de los clientes a la versión 4.16:
- Ver primero si hay equipos duplicados por uuid para hacer merge antes de migrar el cliente
- Una vez revisados los equipos, borrar los que tengan el CID anterior....listar por si acaso la última sync para ver si es posterior o anterior....Con el nuevo servidor, aunque el cliente facilite una uuid antigua, lo tomará como el equipo con el CID más moderno por tener la misma MAC (y no encontrarlo al haberlo borrado) OJO, borrar, no dar de baja!!!!!
- Progresiva por centro?
- Ver primero si hay equipos duplicados por uuid para hacer merge antes de migrar el cliente
#3
Actualizado por Nacho Sancho hace más de 5 años
- Se vuelven a migrar las etiquetas de los equipos que han sufrido cambio de CID por cambio de UUID. En el fichero log de resultado se reflejan los equipos que hay que borrar de la BD (según pone en la incidencia #1288).
- Limpia de errores. Copia de la BD de migasfree (migasfree.sql)
- Parada del servidor migasfree (docker-compose down)
- Copia de seguridad de los archivos de migasfree (/var/lib/migasfree) en /var/lib/migasfree.educa.aragon.es.4.15
- Cambio del fichero de version en env
- Rearranque del servidor migasfree en la nueva versión con docker (docker-compose up)
- Verificación de funcionamiento con MV
- Borrado de los equipos duplicados según el listado generado en el punto 1 - ERROR en la API. Esperando solución...
- Errores
- Posibles nuevas duplicaciones
#4
Actualizado por Nacho Sancho hace más de 5 años
Solucionado y realizado el borrado
Todo parece correcto, se da por actualizada y funcional la versión 4.16
#5
Actualizado por Nacho Sancho hace más de 5 años
Cuando se instala una iso con el cliente anterior (4.13 o el que esté en la iso de Diciembre de 2017) en un equipo que tiene problemas para sacar correctamente el uuid (por ejemplo, sale con 00000-0000...) lo registra con un CID pero aún no sube el inventario. Al ponerle etiquetas o volver a actualizar, como ya tiene el nuevo migasfree-client, saca un uuid diferente (correcto) y al no encontrar el uuid igual (el resultado es difererente), ni la mac (en la primera pasada no la ha registrado todavía) crea un nuevo CID.
Ejemplo: 14686 -> 14700
- Ojo, al etiquetar el equipo antes (al principio, por ejemplo cuando se está en la fase de postinstalación), las etiquetas se las queda el primer CID!!!
Revisar los CID que tienen la mac vacía, buscar si hay otro CID con la misma MAC (se puede sacar el uuid del equipo sin mac) y hacer un merge en el caso de ser necesario por las etiquetas
-- nacho
#6
Actualizado por Nacho Sancho hace más de 5 años
Además de lo anterior...migasfree-server no está haciendo comprobación por mac....están apareciendo equipos que han cambiado de CID creando un nuevo registro ya que se cambia el uuid, pero no comprueba las mac!
-- nacho
#7
Actualizado por Nacho Sancho hace más de 5 años
Comprobar también que a la hora de borrar (revisar los que se han borrado) los CID's antiguos/duplicados, no están en ninguna falla/conjunto
#8
Actualizado por Nacho Sancho hace más de 5 años
Los equipos que han cambiado de CID, al haber cambiado de forma dinámica tienen ya el registro hecho de que se ha activado....deberían correr de nuevo la falla para activarse (o mejor aún, activarlos si estaban activos los equipos que sustituyen)
Ojo, el tema de la migración y activado de los equipos "nuevos" por tener la 4.16 ya se puede ir haciendo, pero el borrado de los anteriores no se debería hacer hasta que se solucione el problema del código en el servidor.
#9
Actualizado por Nacho Sancho hace alrededor de 5 años
- Agrupa equipos por MAC (se supone que es el mismo) Comprueba que el último CID tenga etiquetas. Si no las tiene le asigna las de los equipos anteriores (con misma mac)
- Comprueba y avisa si ésos eqiupos tienen fallas asignadas, para luego actuar sobre ello de forma manual (un cid antiguo con falla implica que el nuevo debería tener). Solo avisa, no actua
- Comprueba y avisa si ésos eqiupos están en conjuntos, para luego actuar sobre ello de forma manual (un cid antiguo en conjunto implica que el nuevo debería estar). Solo avisa, no actua
- Modifica el estado del "nuevo" si los anteriores estaban activos
- Borra los equipos antiguos si tienen uuid=000...MAC, dejando solo el último. De ésta forma, si se instala de nuevo con client antiguo, ahora el server ya sabe que se trata del mismo cid y no creará duplicados.
En futura actualización, en lugar de comprobar fallas y conjuntos y asignar etiquetas, realizará migración....según veamos si es conveniente o no.
Queda pendiente revisar y actuar sobre aquellos que no tienen mac y que se han duplicado también.
#10
Actualizado por Nacho Sancho hace alrededor de 5 años
Se programa script para chequee los posibles equipos con mac vacía (y que tengan uuid 00000.....) y se buscan posibles "candidatos" (que tengan dicha mac asignada)
Se hacen comprobaciones de seguridad (fechas de actualización, identifación de producto igual y cid superior para el nuevo) y en caso de todo ok se procede a realizar la migración al nuevo y borrado del antiguo
Tras las comprobaciones se aplica dicho script (requiere consulta previa a la BD por eficiencia)
Queda pendiente programar la ejecución de ambos scripts de forma periódica...de momento se hará manual
-- nacho
Descripción
- Actualización de las imágenes de migasfree, teniendo en cuenta los commits producidos en la versión base: https://github.com/migasfree/migasfree-docker/commits/master
- Test de la nueva versión en local
- Generación de los nuevos contenedores para vitlainux con la versión 4.16
- Upgrade en producción de las imágenes (fichero .env suficiente)
- Test en producción
- Upgrade de los clientes a la versión 4.16:
- Ver primero si hay equipos duplicados por uuid para hacer merge antes de migrar el cliente
- Progresiva por centro?
Peticiones relacionadas