Ajout d'un répertoire hôte partagé à un conteneur LXC / LXD

19

J'ai expérimenté avec LXC / LXD sur Ubuntu 14.04 et tout fonctionne très bien. J'ai juste besoin de comprendre comment faire fonctionner les répertoires partagés entre ma machine hôte et un conteneur afin que je puisse abandonner Virtualbox une fois pour toutes.

J'ai vu cette page: https://wiki.gentoo.org/wiki/LXD

Ce qui fournit des instructions, mais je continue de recevoir des erreurs.

Quelqu'un connaît-il des instructions simples et claires pour que cela fonctionne? Toute aide très appréciée.

lxc lxd user47227
la source
2
J'ai réussi à monter un répertoire hôte en utilisant: lxc config device add confexample sharedtmp disk path=/tmp source=/tmp/shared. Mais en regardant le répertoire sur le conteneur, le propriétaire et le groupe des fichiers sont définis sur «personne» et «nogroupe» et le montage est en lecture seule.
user47227
Pourriez-vous s'il vous plaît ajouter un peu plus de détails? Qu'avez -vous fait exactement , que vouliez-vous réaliser et que s'est-il passé à la place? Avez-vous rencontré des messages d'avertissement ou d'erreur? Veuillez les reproduire dans leur intégralité dans votre question. Vous pouvez sélectionner, copier et coller le contenu du terminal et la plupart des messages de dialogue dans Ubuntu. (voir Comment poser une bonne question? )
David Foerster
En supposant que vous utilisez un conteneur non privilégié et que le mappage UID / GID est le problème, consultez cette section d'un article sur les mappages d'userns avec LXD. Cependant, cela a probablement été ajouté à LXD après avoir posé votre question.
0xC0000022L
Je ne sais pas quelle version a ajouté cela (je suis sur 2.18) mais si possible, vous pouvez également utiliser le lxc filepour transférer des fichiers entre l'hôte et le conteneur, en utilisant pushet pull.
code_dredd

Réponses:

21

Les instructions sur https://wiki.gentoo.org/wiki/LXD que vous mentionnez sont correctes mais peuvent nécessiter un peu plus d'explications.

Sur l'hôte, vous vérifiez d'abord la propriété du répertoire dans lequel les données du conteneur sont stockées. Courir

sudo ls -l /var/lib/lxd/containers

et vérifiez le propriétaire du conteneur avec lequel vous souhaitez partager le répertoire. Dans mon cas, le uidet les giddeux étaient 100000.

Ensuite, utilisez-les pour modifier la propriété du répertoire que vous souhaitez partager:

sudo chown 100000:100000 /tmp/share_on_host

Partagez le répertoire avec le conteneur de la manière que vous avez indiquée dans votre commentaire:

lxc config device add mycontainer sharedtmp disk \
                  path=/tmp/share_on_guest source=/tmp/share_on_host

Maintenant, dans le conteneur, vous verrez que le répertoire /tmp/share_on_guest(je ne conseillerais pas de monter votre répertoire car /tmpparce qu'il est utilisé par le système pour d'autres choses et a des autorisations spéciales) appartient à root. À partir de là, vous pouvez utiliser chowndans le conteneur pour changer la propriété en appropriée uidet gidpour votre utilisateur dans le conteneur.

En remarque, après avoir changé la propriété du conteneur par exemple en un utilisateur avec uid33, vous verrez sur l'hôte qu'il uidy a maintenant 100033, ce qui est tout à fait logique.

ph0t0nix
la source
Je ne sais pas si c'est juste ma configuration, mais avec LXD v3.0.3 LTS (Ubuntu 18.04 LTS), je n'ai trouvé que des liens symboliques à l'intérieur de /var/lib/lxd/containerscelui pointé vers /var/lib/lxd/storage-pools/lxd/containers(dans ce cas, le dernier lxdbit est le nom de mon pool de stockage ZFS). Tous les conteneurs là-bas semblaient avoir le même 165536 uid / gid lors de l'exécution et détenus par root:rootlorsqu'ils étaient éteints.
deoren
1
Je me rends compte que c'est une vieille question + réponse, mais dans Ubuntu 18.04, je n'ai eu à jouer avec aucune autorisation. Ajoutez simplement le dossier avec lxc configet cela a fonctionné comme un charme!
Apache le
4

Voici une réponse mise à jour à cette question.

Montez le dossier hôte /var/wwwcomme /var/testdans le conteneur.

lxc config device add mycontainer vartest disk source=/var/www path=/var/test
Guest8354542556745
la source
Bienvenue sur Ask Ubuntu! Je recommande de modifier cette réponse pour la développer avec des détails spécifiques sur la façon de procéder. (Voir aussi Comment écrire une bonne réponse? Pour des conseils généraux sur les types de réponses considérées comme les plus utiles sur AskUbuntu.)
David Foerster
3

Vous pouvez affecter des périphériques supplémentaires au conteneur, et ceux-ci peuvent être des dossiers accessibles à l'hôte.

$ lxc config ## display help
...
lxc config device add [<remote>:]<container> <device> <type> [key=value...]
    Add a device to a container.
...

Notez que ce <device>n'est qu'un nom arbitraire que vous attribuez, qui sera utilisé comme ID pour la gestion ultérieure des appareils.

Par exemple, pour monter le dossier hôte "./host" en tant que "/ mnt / host" dans le conteneur ...

lxc config device add mycontainer vartest disk source=$(pwd)/host path=/mnt/host

Il reste un problème - si vous souhaitez que ce dossier soit accessible en écriture par l'hôte et le conteneur, la propriété et les autorisations doivent être configurées en conséquence. Ceci est compliqué par le mode par défaut de LXD qui virtualise les plages numériques pour les idvaleurs d' utilisateur et de groupe . Il existe cependant une solution simple : contournez cette virtualisation en configurant le conteneur pour qu'il s'exécute avec des privilèges équivalents à l'hôte ...

lxc config set <container> security.privileged true

Les implications complètes de cette approche sur la sécurité de l'hôte ne me sont pas claires pour le moment, mais elles semblent être quelque peu «contenues» par la virtualisation. Le risque pratique dépend de comment et pourquoi vous utiliserez le conteneur. Voir les notes techniques sur https://insights.ubuntu.com/2017/06/15/custom-user-mappings-in-lxd-containers

Notez en outre que cette approche fonctionne probablement mieux si vous travaillez normalement dans le conteneur en tant qu'utilisateur non root, comme si vous vous connectez avec ...

lxc exec zesty -- su --login ubuntu
nobar
la source
Il y a un problème avec la connexion non root: le envest différent, en particulier http_proxy. Un exemple DEPANNAGE: sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
nobar
Concernant http_proxy, je pense que la solution la plus simple est probablement d'activer IPV4 comme discuté ici .
nobar
... suivie sudo dhclientdans le récipient - ou le changement manualde dhcpdans 50-cloud-init.cfg. De bons
nobar
1
C'est une mauvaise idée évidente . La recommandation de passer à des conteneurs privilégiés subvertit l'une des avancées de LXD. Alors que LXC 1.x offrait également la possibilité d'utiliser des conteneurs non privilégiés (et oui, même en tant que root), il était un peu plus compliqué de trier les détails. Avec LXD, c'est désormais chose du passé. En outre, qu'est-ce qui est si compliqué de définir des ACL sur un dossier pour permettre à l'UID côté hôte l'accès requis ou pour utiliser la méthode décrite ici ? Ouais, le mappage des UID / GID n'est pas le seul moyen!
0xC0000022L
1

Sur la base de l' excellente réponse de ph0t0nix , je propose l'approche étape par étape suivante pour mon serveur Ubuntu 18.04:

  1. Dans l'hôte, déterminez l'UID du propriétaire de rootfs:

    sudo ls -l /var/lib/lxd/storage-pools/lxd/containers/webserver/rootfs  
id -u root   → 100000

  2. Dans le conteneur, déterminez l'UID d'ubuntu (c'est-à-dire l'utilisateur dans le conteneur):

    id -u ubuntu   → 1000

  3. Créez un dossier partagé dans l'hôte et ajoutez-le au conteneur:

    lxc config device add webserver mydevicename disk path=/home/share_on_guest source=/home/share_on_host

  4. Ajustez l'UID de l'hôte du dossier partagé (UID = hôte UID + invité UID):

    sudo chown 101000:101000 /home/share_on_host

  5. L'invité (utilisateur ubuntu) a désormais accès au dossier partagé et peut ajuster l'accès du conteneur au dossier partagé à l'aide de chmod.

joerg
la source
0

J'ai maintenant une solution sûre et fonctionnelle à ce problème, en utilisant des profils LXD pour gérer le mappage entre UID et GID dans le conteneur et sur l'hôte.

Un résumé très utile peut être trouvé ici:

https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8

user47227
la source
5
Notez que rendre les choses accessibles en écriture est généralement une mauvaise idée du point de vue de la sécurité. Vous devriez probablement envisager d'utiliser des ACL POSIX sur le chemin de l'hôte, en accordant l'accès à l'utilisateur du conteneur en ajoutant une ACL spécifique pour cet uid, puis pour tout autre utilisateur hôte qui a également besoin d'un accès en écriture.
stgraber
1
@stgraber, même si je suis d'accord avec ce que vous avez dit, je n'ai aucune idée de la façon de configurer cela. Certains liens seraient utiles.
s3v3n
Veuillez ne pas recommander les 0777autorisations «s'il vous plaît-pirater-mon-système-et-détruire-mes-données» sans raison apparente! Il n'y a presque jamais de raison à cela, car cela peut être évité avec des modifications plus sensibles comme le changement de propriété (de groupe). -1
David Foerster
Je comprends votre point de vue, mais je ne l'ai utilisé que comme solution de contournement temporaire sur une machine de développement à utilisateur unique, en l'absence de toute autre manière de le faire fonctionner. Depuis lors, j'ai découvert que l'utilisation de profils est le moyen de gérer cela, voir ma réponse modifiée ci-dessus!
user47227
1
Qu'y a-t-il de si difficile à utiliser les ACL ou la méthode décrite ici ?
0xC0000022L