¿Dónde pueden los datos de Ubuntu escribir datos?


30

Las aplicaciones empaquetadas como snaps en Ubuntu se instalan (montan) debajo de la /snap/$SNAPPNAMEubicación. Todo debajo /snapestá montado como un sistema de archivos de solo lectura, por lo que las aplicaciones no pueden escribir en ese espacio, ni en los directorios de otras aplicaciones ni en los suyos.

Si bien hay una home interfaz que las instantáneas pueden especificar para leer / escribir el directorio de inicio del usuario, está reservada por razones de seguridad y el usuario debe conectarla (habilitarla) manualmente.

Entonces, ¿dónde puede una aplicación dentro de un complemento escribir su configuración, datos y otros archivos? ¿Existen API para acceder a ubicaciones especiales de escritura?

Respuestas:


41

Tengo problemas para remitirlo a la documentación, lo que significa que todavía no he tomado mi café (verdadero) o nos falta algo de documentación ( actualización : aquí hay documentación )

Cuando declara aplicaciones en su snapcraft.yaml, se genera un contenedor binario al momento de la instalación y se coloca en él /snap/bin/, con el nombre de su paquete y el nombre de la aplicación (tenga en cuenta que si la aplicación es un servicio, este contenedor es un archivo systemd .service).

Ese contenedor contiene la mayor parte del entorno en el que se ejecutará la aplicación. Las dos variables de entorno más relevantes para esta pregunta son SNAP_DATAy SNAP_USER_DATA.

  • SNAP_DATAes un área de escritura en todo el sistema (in /var/snap/). Esto podría usarse para alojar registros de servicios, por ejemplo.

  • SNAP_USER_DATAes un área de escritura específica del usuario en el directorio de inicio del usuario que ejecuta la aplicación (específicamente /home/<user>/snap/). Esto podría usarse para archivos de configuración específicos del usuario, etc.

Ambos directorios son muy importantes para la funcionalidad de actualización / reversión, ya que ambos están versionados . Es decir, cada versión de un complemento dado tiene su propia copia de estos directorios. Dejame explicarte con un ejemplo.

Supongamos que instala la versión 1 del complemento "foo". Eso creará dos directorios:

  • /var/snap/foo/1( SNAP_DATA)
  • /home/<user>/snap/foo/1( SNAP_USER_DATA)

Ahora digamos que "foo" usa ambos. Tal vez tiene un servicio que aloja una base de datos SNAP_DATAy un binario que usa archivos de configuración SNAP_USER_DATA.

Ahora se lanza la versión 2 de "foo", y se actualiza automáticamente. Lo primero que sucede es que /var/snap/foo/1se copia /var/snap/foo/2y /home/<user>/snap/foo/1se copia /home/<user>/snap/foo/2. Entonces se enciende la nueva versión. Debe notar que se está ejecutando en datos antiguos, y tal vez tenga algunas migraciones de bases de datos para ejecutar en la base de datos SNAP_DATA. Hace eso y se va.

Ahora digamos que esas migraciones fallan por cualquier razón, y esta aplicación necesita ser revertida. Comienza usando la versión anterior de la aplicación / snap / foo, donde SNAP_DATAapuntaba /var/snap/foo/1y SNAP_USER_DATAapuntaba /home/<user>/snap/foo/1. Esto recoge las cosas de la versión anterior en el punto antes de que se ejecutaran las migraciones, ya que esas operaciones se ejecutaron en una copia de los datos.

En pocas palabras: no use la homeinterfaz para almacenar datos que puede almacenar SNAP_DATAo SNAP_USER_DATA, ya que son una parte integral de la estrategia de actualización / reversión. ¡Aprovecha de ellos!

ACTUALIZACIÓN para v2.0.10:

También se introdujeron dos nuevos directorios de datos:

  • SNAP_COMMONse sienta al lado SNAP_DATA, pero está específicamente sin versión . Cada revisión del complemento específico tiene acceso a este directorio, por lo que no se copia en la actualización / reversión, etc. Esto podría usarse para archivos particularmente grandes y no versionados (por ejemplo, datos sin procesar que no son realmente específicos de la versión).

  • SNAP_USER_COMMONse sienta al lado SNAP_USER_DATA, pero de nuevo está específicamente sin versión . Puede usarse para almacenar datos no específicos de la versión por usuario.

ACTUALIZACIÓN para v2.15:

Los archivos colocados dentro /snap/binya no son contenedores que definen el entorno, sino enlaces simbólicos a /usr/bin/snap. Entonces, la forma de determinar el entorno en el que se ejecuta una aplicación sería utilizar snap run --shell <snap>.<app>, por ejemplo:

$ sudo snap install hello-world
$ snap run --shell hello-world
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

$ env | grep SNAP
SNAP_USER_COMMON=/home/kyrofa/snap/hello-world/common
SNAP_REEXEC=
SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:
SNAP_COMMON=/var/snap/hello-world/common
SNAP_USER_DATA=/home/kyrofa/snap/hello-world/27
SNAP_DATA=/var/snap/hello-world/27
SNAP_REVISION=27
SNAP_NAME=hello-world
SNAP_ARCH=amd64
SNAP_VERSION=6.3
SNAP=/snap/hello-world/27

1
¿No SNAP_USER_COMMONse crea el directorio automáticamente por snapd? La secuencia de comandos del iniciador /snap/bin/no lo crea, y la creación manual dentro del complemento falla (permiso denegado). Sin snap run appembargo, la ejecución crea esa carpeta (pero el comando falla con execv failed: No such file or directory... No tengo idea de cómo usar ese comando).

1
Sí, debería serlo, pero no lo es (un error que se corrigió en la próxima versión donde snap runse usa).
Kyle

1
Tenga en cuenta que la ejecución rápida se utiliza a partir de v2.15.
Kyle

2
Parece que el documento se actualizó, aquí la página de referencia snapcraft.io/docs/reference/env
user.dz

2
Dos años después, ¿ya tomaste café? Todavía no hay documentación sobre dónde las aplicaciones Snap pueden escribir datos en el sistema de archivos (virtual o host). Eso no me ofrece una gran inspiración al tratar de comprender los detalles básicos obvios sobre las instantáneas.
Dan Nissenbaum
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.