Où les snapshots Ubuntu peuvent-ils écrire des données?

Les applications emballées sous forme de snapshots dans Ubuntu sont installées (montées) sous l' /snap/$SNAPPNAMEemplacement. Tout sous /snapest monté comme un système de fichiers en lecture seule, donc 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 une home interface que les snaps peuvent spécifier pour lire / écrire le répertoire personnel de l'utilisateur, elle est réservée pour des raisons de sécurité et doit être connectée (activée) manuellement par l'utilisateur.

Alors, où une application à l'intérieur d'un composant logiciel enfichable peut-elle écrire sa configuration, ses données et d'autres fichiers? Existe-t-il des API pour accéder à des emplacements inscriptibles spéciaux?

J'ai du mal à vous référer à la documentation, ce qui signifie que je n'ai pas encore pris mon café (vrai) ou qu'il nous manque une documentation ( mise à jour : une documentation ici )

Lorsque vous déclarez des applications dans votre snapcraft.yaml, il en résulte un wrapper binaire généré lors de l'installation et placé dans/snap/bin/ , nommé d'après votre nom de package et d'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 s'exécutera. Les deux variables d'environnement les plus pertinentes pour cette question sont SNAP_DATAet SNAP_USER_DATA.

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

• SNAP_USER_DATAest une zone inscriptible spécifique à l'utilisateur dans le répertoire personnel 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 . Autrement dit, chaque version d'un composant logiciel enfichable donné a sa propre copie de ces répertoires. Permettez-moi de vous expliquer avec un exemple.

Supposons que vous installez la version 1 du composant logiciel enfichable "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 qu'il a 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.

Maintenant, la version 2 de "foo" est sortie et elle est automatiquement mise à jour. La première chose qui se produit est /var/snap/foo/1copiée /var/snap/foo/2et /home/<user>/snap/foo/1copiée dans /home/<user>/snap/foo/2. Ensuite, la nouvelle version démarre. Il devrait remarquer qu'il fonctionne sur d'anciennes données, et peut-être qu'il a des migrations de base de données pour s'exécuter vers la base de données SNAP_DATA. Il fait cela, 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_DATApointait /var/snap/foo/1et SNAP_USER_DATApointait /home/<user>/snap/foo/1. Cela reprend les choses sur l'ancienne version au point avant l'exécution des migrations, car ces opérations ont été exécutées sur une copie des données.

Pour faire court: n'utilisez pas l' homeinterface pour stocker des données dans lesquelles vous pouvez stocker SNAP_DATAou SNAP_USER_DATA, car elles font partie intégrante de la stratégie de mise à niveau / restauration. Profitez-en!

MISE À JOUR pour v2.0.10:

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

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

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

MISE À JOUR pour v2.15:

Les fichiers placés à l'intérieur /snap/binne sont plus des wrappers qui définissent l'environnement, mais des liens symboliques vers /usr/bin/snap. Ainsi, la façon de déterminer l'environnement dans lequel une application s'exécute serait d'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