Autoactualizar update-minino.sh

[aosucas499]

Me ha surgido la idea de auto-actualizar el update-minino.sh para nosotros y para aquellos que no quieran actualizar con pendrive y volver a instalar.

Había pensado dos opciones:

1. Añadirlo como una opción seleccionable al customize-minino.
2. Archivo desktop que se ejecute al inicio en /etc/xdg/autostart

Otra duda que me surje es si debería de hacerse actualizando simplemente el script a la versión más nueva esperando a que el administrador la ejecute o que incluso se ejecute el update-minino.sh una vez actualizado, cosa que podría traer problemas, al menos con la idea 2. Te adjunto la idea.

[jasvazquez]

El problema lo encuentro principalmente en conocer el "punto de partida": necesitaríamos conocer qué versión concreta hay en un equipo para poder llevarlo a la última versión.

Se me ocurre evaluar (que conste "en acta" que lo tenía anotado porque lo estaba viendo venir 😅 ) el uso de TimeShift (acá el "git de linux") y sus snapshots para intentar evitarnos el tener que gestionar versiones de Minino.

Eso sí, es un cambio importante y requerirá más de una prueba 😉

[aosucas499]

Para tomarlo con calma haciéndolo así. Miraré la herramienta cuando tenga algo más de tiempo. De todas maneras,¿ tú crees que con lo que vamos a ir aplicando en el update-minino.sh de instalar o borrar cuatro cosas es necesario eso?

[jasvazquez]

Y tanto... como para una versión nueva "monotemática" que sólo incluya esta funcionalidad.

Creo que debemos:

1. centrarnos en cerrar las pocas tareas (que no son IDEA) que nos quedan ahora mismo
2. pulirlas para que todo esté "redondo" (y funcione correctamente)
3. publicar esa versión (antes de seguir "inventando" mejoras)

O, lo que es lo mismo... "memento mori" compi 😉

[jasvazquez]

Yo creo que, ahora mismo, deberíamos centrarnos en lo que tenemos, olvidarnos de esta idea (por mucho que me esté gustando) y si alguien quiere actualizar el equipo, que lo haga manualmente.

Ya implementaremos el Minino-TDE release "autoupdate" con la mejor solución que encontremos entre las que estamos planteando ¿no te parece? 🤔

[aosucas499]

Me parece buena idea y más ahora que viene tiempos de curro máximo. Lo miramos en navidades.😉

[jasvazquez]

Sea, como IDEA queda y ya estas navidades le damos una vuelta al tema 👍🏻

[jaimecarrascogarcia]

Creo que la idea, teniendo en cuenta...que muchos "equipos" necesitan "mejoras", sería mas que recomendable. Si fuera posible, añadirla al customize "El actualizador de Sistema" ....al igual que añadir por poner un ejemplo en customize:

"Toshiba nb500 Fix driver sonido" haces click y solucionado.....

Ya me decís que os parece...

[jasvazquez]

Pues me parece que si es un "fix" debe ir "de serie" o, lo que es lo mismo: que si se detecta el modelo de equipo, se solucione automáticamente.

Por _customizeminino.sh entiendo dar al usuario la posibilidad de elegir comportamientos de Minino y que funcione, per se, no es algo opcional 😉

[jasvazquez]

@jaimecarrascogarcia ¿debo entender que la tarea #47 que creaste es exactamente esta en la que estamos? 🤔

[jaimecarrascogarcia]

Efectivamente compañero, te respondo a ambos comentarios afirmativamente. Lo que propongo es exactamente esto en lo que estamos. Y por otra parte sería genial, que el sistema detectara el modelo del equipo y lo solucionara automáticamente....espero lo puedas conseguir, yo aun no llego a tanto....aunque intentaré ayudar en lo que pueda @jasvazquez MUCHAS GRACIAS!

[jasvazquez]

Gracias a ti por tomarte la molestia de comentar y aportar tu experiencia con Minino-TDE. Sin vuestras pruebas, vamos un poco a "ciegas", Jaime Opto por cerrar entonces la otra tarea para que no se acumule trabajo "inncesariamente" 👍🏻

[jasvazquez]

Quizás en este hilo hemos estado mezclando temas y no sea necesario un Timeshift simplemente para gestionar los cambios de _customizeminino (tema distinto serían las actualizaciones de Minino en _updateminino)

Tras los últimos cambios en el código de customize sería factible añadir/eliminar opciones (y detectar cuáles han sido usadas, para marcarlas como tal) en el listado que ofrece.

Respecto a su actualización siempre se podría hacer (al iniciar el script) una comprobación de versión contra el servidor de Github y, si hay una versión más reciente aplicar un git pull 🤔

Se me empieza a encender la "mono neurona" con esta "idea cúbica" (a la que debo darle patadas para poner redonda): dejadme que lo "macere" mañana (como "thread" de baja prioridad) y confío en poder montar algo como mi contribución habitual de fin de semana (que es cuando normalmente saco algo de tiempo para "pruebas y experimentos" 👍🏻

[jasvazquez]

Tras implementar la actualización automática de customize-minino.sh se me ocurre una solución que rompería con el enfoque actual de Minino pero que evitaría a los compañeros tener que estar "quemando" ISOs y actualizando equipos "desde cero" en los que ya tienen instalado el sistema.

La idea es delegar en cada usuario la ejecución de update-minino.sh para ello:

• Utilizamos la comprobación de versión actualizada contra github (tal y como se hace actualmente en customize-minino.sh)
• Añadimos comprobaciones a cada función de update-minino.sh (de modo que sólo se aplicarán aquellas que todavía no se hayan lanzado contra el sistema)
• Metemos (¿en el arranque de Minino?) la comprobación de versión y, si hay cambio, preguntamos al usuario si quiere actualizar el equipo (quizás mejor como un pop-up no intrusivo como hacen la mayoría de distribuciones)
• Cada vez que saquemos una nueva versión "estable" de Minino, generamos ISO para el que quiera/necesite empezar de cero (bien por no haberlo instalado nunca, bien porque se haya cargado algo 🤣 )

Tras revisar lo que hacemos ¿qué sentido tiene modificar Minino-base, crear la ISO y distribuirla?

Al fin y al cabo esa ISO lo que hace es instalar el sistema base y hacer un rsync de los cambios (debidos a la instalación de paquetes o modificación de ficheros) así que el que tenga su Minino-TDe instalado, sólo tendría que aplicar los mismos cambios que hacemos nosotros para generar la ISO o, lo que es lo mismo: aplicar los cambios de update-minino.sh que no haya aplicado ya ¿No os parece? 🤔

[aosucas499]

Esa es una idea genial, creo que la hablamos al principio del proyecto, aunque ahora con el código que has creado tiene forma. Seguro que los compañeros adorarán un minino que se actualice sin tener que instalar otra vez. Bravo!

[jasvazquez]

Pues la estoy viendo todavía mejor: si lo hacemos así podríamos documentar la forma de crear las ISOs (ahí igual se puede "invitar" el amigo @jaimecarrascogarcia 😅)

De esta forma, cada profesor/a podría personalizar (usando customize-minino.sh) cómo quiere que estén los ordenadores que va a instalar y generar una ISO personalizada a sus necesidades y centro.

Ya sólo tendría que ir con el pendrive (equipo por equipo) dejándolos como le interesa sin tener que estar abriendo customize-minino.sh en todos y cada uno de ellos 🤔

[jaimecarrascogarcia]

Lo que mandeis, aunque me tendreis que explicar como se hace compis!!!!

[jasvazquez]

Genial, gracias Jaime. Te remito a la tarea #66 para seguir la conversación 👍🏻

[aosucas499]

Si descargo el git e instalo update-minino desde la versión anterior a esta que tenía en la máquina virtual, no hay problema, pero si monto en la máquina virtual nuestro minino desde el que partimos "fix-centros", descargo nuestro proyecto (git clone) y ejecuto update-minino, en cada inicio del sistema o tras cerrar e iniciar sesión, me muestra consola de comandos para poner la contraseña del usuario. Supongo que por el script que se autoinicia para ver si hay versión nueva y ejecutar la actualización.

[jasvazquez]

Anoto revisarlo... gracias compañero 👍🏻

[jasvazquez]

@aosucas499 en teoría ya tendría el mismo comportamiento en las dos versiones que mencionas.

No obstante (salvo que demos permisos de administrador a /usr/bin/update-minino o lo incluyamos en el fichero de sudoers) seguirá pidiendo clave tan pronto comience a "hacer cosas" ya que update-minino como bien sabemos, toca ficheros del sistema e instala programas.

Agradecería comprobases si ya no te da problemas en fix-centros ya que no me fío de la máquina virtual que tengo de ella 😅

[aosucas499]

Intento probarlo esta misma tarde, gracias compañero. No habría problema en incluir en sudoers, tenemos el código que lo hace para el ntpfix, serían dos minutos si lo ves apropiado.

[jasvazquez]

No corre prisa... yo me he sentado un rato a cerrar esto y lo voy a dejar por hoy.

Anoto como nueva tarea el tema de incluirlo en sudoers pues aunque poco, requiere desarrollo, estamos ante nueva funcionalidad y requerirá alguna que otra prueba (y esta tarea ya está "creciendo demasiado" y soy minimalista, a parte de cabezón, para estas cosas 🤣 😅 )

¿Divide y vencerás? Naaahhh... mas bien manías 😉

[aosucas499]

He probado con la versión fix-centros y no funciona, al ejecutar update-minino se queda muerto, el cursor en blanco de la terminal parado hasta la eternidad.

[aosucas499]

Si quieres volvemos a la versión anterior y añado update-minino a sudoers. Menos dolor de cabeza...

[profeIAP]

No tiene sentido (salvo que update-minino no esté en /usr/bin)

¿Dónde puedo descargar la fix-centros? (ya no me fío de la vbox que tengo)

[aosucas499]

No sé, tenía una snapshot desde la que siempre parto que es la instalación de fix centros fix centros

[aosucas499]

Creo que podemos cerrar este problema y dado como finalizado con la release 1.2.3 y 1.2.4

Mil gracias por esta función tan deseada y productiva !!!

[jasvazquez]

No termino de ver claro que esté terminado (aunque todavía no he tenido tiempo de probar las releases que mencionas)

Este fin de semana estuve trabajando en el tema y, cuando creía tener la solución, descubrí el fallo que has comentado de ejecutar siempre update-minino (lo cual, aunque no sea molesto, no procede ni me parece "ético")

Llevo una semana bastante mala de trabajo y de salud (poca cosa pero no tengo centrada la cabeza como para cerrar el tema) pero descuida que le echo un vistazo lo antes posible 😅

[aosucas499]

Vaya por Dios compañero, espero que no sea nada y mejores. Instentaré echar ratillos probando y jugando con las releases a ver si te ahorro tiempo y lo soluciono.

[profeIAP]

Descuida, poca cosa... gracias por los "buenos deseos" 👍🏻

[jasvazquez]

Compi, quedo a la espera de que puedas hacerle alguna prueba (mañana si éso 😉 )

[aosucas499]

Excelente trabajo compañero. He probado y aquí tienes el testing:

1. Arrancando desde la release 1.2.7 se ha puesto a actualizar a la 1.2.8, pidiéndome confirmación. Puedes observar en estas imágenes el aviso y la fecha de update-minino a días previos a tu nueva release.

2. En esta imagen después de haberse actualizado. Puedes observar como la fecha y tamaño de update-mininoz que indica que se ha actualizado bien y abriendo el archivo que incluye la nueva variable REPO_GITHUB.

Se observa todo bien. He vuelto dos veces a la release 1.2.7, una vez he probado a actualizar sin conexión a Internet, ha mostrado el aviso y no lo ha actualizado y otra vez borrando update-minino de /usr/bin y dándole a actualizar (vi en el código que añadiste esta posibilidad). En ambas ha ido genial, trabajo de crack!!!

[aosucas499]

También comentar que ya no sale xterm haciendo todo el trabajo en cada inicio si update-minino está actualizado a la última release. Da un pequeño pantallazo en cada inicio y desaparece, cosa que ya la veo aceptable.

He hecho otra prueba que no estoy seguro, ya que no me queda hoy más tiempo. Creo recordar que el check que hace update-minino sobre si existe customize-minino como app del sistema era comprobar si existe en /usr/bin, no?

He borrado /usr/bin/customize-minino y he cerrado la sesión y he vuelto a entrar suponiendo que update-minino ve que no existe e instala nuevamente, pero no ha ocurrido.

[jasvazquez]

Me alegra que te guste Andrés (gracias)

Gestionar la ausencia de /usr/bin/update-minino (de customize no recuerdo haber incluido nada) es un "work in progress" y lo dejé por un comportamiento "curioso" con el que no me quedaron más ganas de pelear el pasado fin de semana 😅 . Si lo consideras interesante le dedico algo más de tiempo pero ten en cuenta un detalle: la idea es partir de una ISO que ya tiene update-minino en /usr/bin, si alguien lo ha borrado que "apechugue" con su "osadía" ¿no? 😉

Para resumir tras la reflexión anterior:

• ¿abrimos nuevamente la tarea y pulo la ausencia de update-minino?
• ¿o damos por bien cerrada la tarea y nos vamos planteando "salir a la calle" con la nueva release?

[aosucas499]

No! Vamos a por la release, solo te lo decía porque pensé que lo incluiste. Genial así!!!

[aosucas499]

Dejo apuntado aquí (tras 1 hora calentándome la cabeza) que update-minino no solo necesita nueva release para actualizar, también necesita algún cambio en su código.

[profeIAP]

cosas de los "hashes" 🤣😅

[jaimecarrascogarcia]

Compañeros, después de probar la magnífica ISO "testing", me encuentro con el problema de que en los Toshiba NB500, comparándolos con otros modelos en concreto, la mayoría de los reinicios de sistemas no actualiza ya que no hay conexión a internet. El problema es que el "auto update" se inicia antes que la conexión, y a este no le da tiempo a conectarse a tiempo. Creo que sería interesante, hacer alguna pequeña modificación en el "script" autoupdate para que se inicie siempre que haya conexión a internet.....de lo contrario será complicado actualizar estos dispositivos que tarden en coger la wifi mas de la cuenta....

[aosucas499]

Mismo problema con las lamentablets, dan fallo siempre al iniciar, si cierras e inicias sesión ya detecta pero de inicio la red tarda más en cargarse. Voy a probar a meterle unos segundos de sleep a la función.

[aosucas499]

Creo que solventado f937435031f21ec0af5185745d6501f03ca5f5f3 Nueva release