web-dev-qa-db-fra.com

Où les captures instantanées Ubuntu peuvent-elles écrire des données?

Les applications empaquetées sous forme de clichés sous Ubuntu sont installées (montées) à l'emplacement /snap/$SNAPPNAME. Tout ce qui se trouve sous /snap est monté en tant que système de fichiers en lecture seule. Par conséquent, les applications ne peuvent pas écrire sur cet espace, ni dans les répertoires d'autres applications, ni dans le leur.

Bien qu'il existe un homeinterface que les instantanés puissent spécifier de lire/écrire le répertoire de base de l'utilisateur, il est réservé pour des raisons de sécurité et doit être connecté manuellement (activé) par l'utilisateur.

Alors, où une application dans un instantané peut-elle écrire sa configuration, ses données et d’autres fichiers? Existe-t-il des API permettant d'accéder à des emplacements spéciaux en écriture?

snapubuntu-core
29
David Planella

Je ne parviens pas à vous référer à la documentation, ce qui signifie que je n’ai pas encore pris mon café (vrai) ou que nous manquons de la documentation ( mise à jour : n peu de documentation ici )

Lorsque vous déclarez des applications dans votre snapcraft.yaml, un wrapper binaire est généré lors de l'installation et placé dans /snap/bin/, nommé d'après votre paquet et le nom de l'application (notez que si l'application est un service, ce wrapper est plutôt un fichier systemd .service). .

Ce wrapper contient la plupart de l'environnement dans lequel l'application sera exécutée. Les deux variables d'environnement les plus pertinentes pour cette question sont SNAP_DATA et SNAP_USER_DATA.

  • SNAP_DATA est une zone inscriptible à l'échelle du système (dans /var/snap/). Cela peut être utilisé pour héberger des journaux de services, par exemple.

  • SNAP_USER_DATA est une zone inscriptible spécifique à l'utilisateur dans le répertoire de base de l'utilisateur exécutant l'application (en particulier /home/<user>/snap/). Cela peut être utilisé pour les fichiers de configuration spécifiques à l'utilisateur, etc.

Ces deux répertoires sont très importants pour la fonctionnalité de mise à niveau/restauration, car ils sont tous deux versionnés . C'est-à-dire que chaque version d'un composant logiciel enfichable donné possède sa propre copie de ces répertoires. Laissez-moi vous expliquer avec un exemple.

Supposons que vous installiez la version 1 de la capture "foo". Cela créera deux répertoires:

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

Maintenant, dites "foo" utilise les deux. Peut-être a-t-il un service qui héberge une base de données dans SNAP_DATA et un binaire qui utilise des fichiers de configuration dans SNAP_USER_DATA.

La version 2 de "foo" est maintenant disponible et elle est automatiquement mise à jour. La première chose qui se passe est que /var/snap/foo/1 est copié dans /var/snap/foo/2 et /home/<user>/snap/foo/1 est copié dans /home/<user>/snap/foo/2. Ensuite, la nouvelle version est lancée. Il convient de noter qu'il fonctionne sur d'anciennes données et qu'il existe peut-être des migrations de base de données à exécuter vers la base de données dans SNAP_DATA. Il fait ça, et c'est parti.

Supposons maintenant que ces migrations échouent pour une raison quelconque et que cette application doit être annulée. Il commence à utiliser l'ancienne version de l'application/snap/foo, où SNAP_DATA désignait /var/snap/foo/1 et SNAP_USER_DATA désignait /home/<user>/snap/foo/1. Cela reprend les éléments de l'ancienne version au moment où les migrations ont été exécutées, puisque ces opérations ont été exécutées sur une copie des données.

En résumé: n'utilisez pas l'interface home pour stocker les données que vous pouvez stocker dans SNAP_DATA ou SNAP_USER_DATA, car elles font partie intégrante de la stratégie de mise à niveau/d'annulation. Profitez d'eux!

UPDATE pour v2.0.10:

Deux nouveaux répertoires de données ont également été introduits:

  • SNAP_COMMON est assis à côté de SNAP_DATA, mais est spécifiquement non versionné . Chaque révision de la capture spécifique a accès à ce répertoire. Par conséquent, il n'est pas copié lors de la mise à niveau/restauration, etc. Cela peut être utilisé pour des fichiers particulièrement volumineux non versionnés (par exemple, des données brutes qui ne sont pas vraiment spécifiques à la version).

  • SNAP_USER_COMMON est assis à côté de SNAP_USER_DATA, mais est de nouveau spécifiquement non versionné . Il peut être utilisé pour stocker des données non spécifiques à la version par utilisateur.

UPDATE pour v2.15:

Les fichiers placés dans /snap/bin ne sont plus des wrappers définissant l'environnement, mais des liens symboliques vers /usr/bin/snap. Donc, la manière de déterminer l'environnement dans lequel une application s'exécute consiste à utiliser snap run --Shell <snap>.<app>, par exemple:

$ 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
41
Kyle