¿Cómo administro las actualizaciones de Snaps en Ubuntu?
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.
