Durante su cátedra Filosofía Peronista, Juan Perón expone sobre las concepciones cósmicas en el quehacer humano, así como detalla cómo definir las actualizaciones de paquetes Snaps en Ubuntu.
(...)
El software responde - por designio - a un ciclo que podremos encontrar en todos los órdenes de la vida. Sabemos que en el microcosmos la célula habita y se organiza por un instinto que creemos programado. En nuestro ambiente diremos que los hombres nos organizamos en tribus y Movimientos, que también creemos programados. Y en el macro cosmos - donde a una escala mayor - los cuerpos operan en el mismo sentido y regidos por la misma programación natural, que es en definitiva aquella que lo rige todo.
Decía entonces que el software debe oficiarse en lo mismo que la célula, los hombres, o las galaxias: ha de actualizarse en su descendencia, so pena de envejecer y desaparecer. A menudo estas actualizaciones traen mejoras, o parches de seguridad vital. Pero al no ser creación divina sino obta de los hombres, ¡ay! a veces portarán errores de origen que son importantes de minimizar y evitar.
Solo un tonto sometería un ambiente de misión crítica a la actualización a la pavota. En tales sistemas es importante lograr un alto grado de supervisión y precisión, y de ello seremos los encargados como Conductores de Sistema.
No es secreto para nadie que - de un tiempo a esta parte- Ubuntu ha adoptado junto con los paquetes de software Deb similares a los de Debian, los paquetes de software autocontenidos Snaps. Estos permiten operar en un sentido idealmente más estanco, al incorporar en sí mismos las dependencias de terceros paquetes de software.
Han de saber que no soy muy adepto a los mismos y los evito en Ubuntu todo lo que sea posible, prefiriendo versiones debianizadas. Algunos me han preguntado porqué no instalo directamente Debian en lugar de Ubuntu, y puedo responder que es una propuesta válida, pero sobre gustos no hay nada escrito, y los peronistas lo saben...
Aún así, los Snaps incluyen poco conocidos mecanismos de actualización automática. Mediante ellos, el residente de Snaps revisa la Tienda de Snaps para comprobar si se han lanzado nuevas versiones de las mismas. Lo típico es que esta revisión se produzca unas cuatro veces por día, y en la vasta mayoría de los casos, se llevará a cabo sin problemas.
Sin embargo, no podemos dejar de saber que en ciertos casos las actualizaciones de Snaps podrían tener que ser diferidas o pospuestas, o simplemente llevadas a cabo con un nivel de control más refinado y mayor. Existen varias maneras de hacer esto.
Control de Revisión de los Snaps
El tiempo de refresco en el cual se revisan las actualizaciones de los snaps es gobernado utilizando cuatro opciones de programación para todo el sistema. Estos opciones son:
- Refresh.timer: Define la frecuencia de temporizador de actualización. Este parámetro puede usarse para definir cuándo se revisarán la disponibilidad de actualizaciones para los snaps, de manera tal que no entren en conflicto con otras actividades, tales como reuniones laborales, acciones de resguardo de datos o actividades críticas similares.
- Refresh.hold: Pone en espera el siguiente revisión de actualizaciones hasta la hora y fecha definida. Esta opción de espera nos permitirá posponer las actualizaciones hasta por los siguientes 60 días. Podremos utilizarla en combinación con la configuración del temporizador para especificar una ventana de tiempo muy específica para que se produzca la actualización de snaps.
- Refresh.metered: Permite pausar la revisión de actualizaciones toda vez que la conexión a la red esté medida. Vean señores, por defecto la revisión de snaps permanece activada aún sobre conexiones de red medidas. Sin embargo, podríamos querer conservar uso de transferencias de datos o costos en ciertas conexxiones, pausando las revisiones de actualización de snaps si estamos bajo tales condiciones.
- Refresh.retain: Configura cuántas revisiones de un snap quedarán almacenadas y retenidas en el sistema. Lo normal es que se conserven las últimas versiones de los snaps instalados.
La combinación de estas cuatro configuraciones os permitirán una buena flexibilidad para controlar las actualizaciones de snaps de vuestro sistema. En particular, las opciones timer ("temporizador") y hold ("en espera") pueden usarse para crear la ventana temporal en la que quisiéramos realizar la actualización de paquetería snap. De esta forma podríamos preveer las tareas requeridas pre y post actualización (chequeos de funcionalidad, respaldo de datos críticos, etcétera).
Configuración del tiempo para Snaps
Observemos algunos ejemplos prácticos, pues suelen explicarlo todo, como decía Napoleón.
Supongamos que deseamos configurar nuestras actualizaciones de snaps para que se lleven a cabo únicamente durante los horarios de la noche, entre las 01:00 y las 2:00 de la mañana (en el formato de 24 horas). Esto lo definiríamos con un comando de organización:
sudo snap set system refresh.timer=01:00-02:00
Conforme hayamos configurado nuestra ventana horaria de actualización de snaps, podríamos también querer observar lo que nos reporta nuestro sistema. Para ello ingresamos:
snap refresh --time
...a lo cual nuestro GNU con Linux debería devolvernos algo como:
timer: 01:00-02:00
last: hoy a las 17:19 AR3
next: hoy a las 01:00 AR3
Existen algunas variaciones disponibles para este ordenamiento que podríamos considerar. Podríamos querer conservar la capacidad de configurar el horario de actualizado para horas específicas, o bien ventanas temporales para cada día de la semana. O bien podríamos querer omitir ciertos días, o plantear en qué semana particular de un mes querríamos realizar dichas actualizaciones de snaps. Para ello podremos usar los valores 1-4 para definir las semanas del mes. Ej, mon3 será el tercer lunes de cada mes, mientras que 5 denota la última semana del mes, ya que ningún calendario en la tierra actual cuenta con más de 31 días.
Al configurar el intervalo de espera requiere ingresar un formato de fecha específico que conforme el estándar RFC 3339. Esto puede sonar muy extremo, pero es una convención. Podrán utilizar los siguientes comandos de referencia para convertir las fechas deseadas al formato correcto:
date --date="TMZ AAAA-MM-DD HH:MM:SS" +%A-%m-%dT%H:%M:%S%:z
Por ejemplo:
date --date="AR3 2020-08-01 13:00:00" +%Y-%m-%dT%H:%M:%S%:z
2020-08-01T13:00:00+01:00
De esta manera podremos configurar el valor de refresco utilizando la siguiente cadena formateada de fecha:
sudo snap set system refresh.hold=2020-08-01T13:00:00+01:00
sudo snap get system refresh.hold
2020-08-01T13:00:00+01:00
Una vez que este tiempo en espera esté configurado, podremos revisar el horario de refresco nuevamente:
snap refresh --time
Temporizador: 01:00-02:00
last: hoy a las 17:19 AR3
hold: en 31 días, a las 13:00 AR3
next: mañana a las 01:00 AR3 (pero en espera)
Como es evidente, la información combina los parámetros tanto de las configuraciones del timer y hold. La siguiente actualización sería mañana a la 1PM, como se define por el temporizador, pero no se llevará a cabo (por 31 días) hasta que el período de actualización expire.
De manera similar, podremos configurar las actualizaciones sobre conexiones medidas. Al configurar el valor en "hold" ("en espera"), se impedirán las actualizaciones, mientras que el cambiar los valores a "null" ("nulo") permitirán que las actualizaciones se produzcan o continúen. Podremos entonces utilizar
sudo snap set system refresh.metered=hold
...o bien:
sudo snap set system refresh.metered=null
Indudablemente podremos combinar esta opción con la del temporizador o en espera para crear una rutina granular y precisa de actualización que no interferirá con las tareas críticas, y aseguren la consistencia máxima buscada. A la vez, también nos permitirán así recibir los parches funcionales y de seguridad que necesitemos.
Entonces, ocasionalmente podríamos querer revisar qué snaps se actualizarán durante la próxima refrescada. Esto nos dará una idea de la lista pendiente de nuevas revisiones de snaps que recibirá nuestro sistema.
snap refresh --list
Nombre Versión Rev Publicador Notas
lxd 4.3 16044 canonical/ -
snapcraft 4.1.1 5143 canonical/ classic
Ahora, la lista completa de los snaps instalados será mayor. Por ejemplo, el sistema actualmente tiene la versión 4.2 de lxd instalado:
snap list lxd
Nombre Versión Rev Rastreo Publicador Notas
lxd 4.2 15878 latest/stable canonical/ -
Noción de refresco
Esta es otra característica que podremos utilizar para controlar las actualizaciones. En algunos casos podríamos querer ejecutar una tarea vital que no debe ser interrumpida de manera alguna. Para tal fin, podremos utilizar la opción de noción de refresco para hacer que la aplicación no sea ejecutada mientras se ejecuta. Si intenta ejecutar una actualización manual del Snap mientras está en ejecución (y estamos usando esta funcionalidad), recibiremos un mensaje del sistema similar al siguiente:
snap refresh okular --candidate
error: cannot refresh "okular": snap "okular" has running apps (okular)
Como hemos visto, las actualizaciones automáticas no pueden considerarse una lista sábana a la cual podemos votar sin pensar. Esto es así pues los medios puestos a nuestra disposición requieren un estudio concienzudo. Los sistemas GNU con Linux para Escritorio, destinados a Servidor e bien dispositivos conectados, emanan requermientos y sensibilidades particulares que no podemos soslayar, y son estos los que motivan un mecanismo de actualizción bastante extenso y configurable.
La combinación práctica de poder disponer horarios de actualización, retrasar las mismas hasta por 60 días, sumadas a la funcionalidad de conexión de datos medidas, y noción de refresco e inhibición de actualización que tienen los snaps y un buen rango de opciones, nos permiten establecer una política pragmática de conducción, con la cual llevar a cabo un régimen de actualizaciones de software robusto y confiable.
