Aggiunta di una directory host condivisa a un contenitore LXC / LXD


19

Ho sperimentato LXC / LXD su Ubuntu 14.04 e tutto funziona alla grande. Devo solo capire come far funzionare le directory condivise tra la mia macchina host e un container in modo da poter abbandonare Virtualbox una volta per tutte.

Ho visto questa pagina: https://wiki.gentoo.org/wiki/LXD

Il che fornisce istruzioni, ma continuo a ricevere errori.

Qualcuno è a conoscenza di istruzioni semplici e chiare per farlo funzionare? Qualsiasi aiuto molto apprezzato.


2
Sono riuscito a montare una directory host utilizzando: lxc config device add confexample sharedtmp disk path=/tmp source=/tmp/shared. Ma guardando la directory sul contenitore, il proprietario e il gruppo per i file in essa contenuti sono impostati su "nobody" e "nogroup" e il mount è di sola lettura.
user47227,

Potresti aggiungere qualche dettaglio in più? Cosa hai fatto esattamente , cosa volevi ottenere e cosa è successo invece? Hai riscontrato messaggi di avviso o di errore? Si prega di riprodurli nella loro interezza nella tua domanda. È possibile selezionare, copiare e incollare il contenuto del terminale e la maggior parte dei messaggi di dialogo in Ubuntu. (vedi Come faccio una buona domanda? )
David Foerster,

Supponendo che tu stia utilizzando un contenitore senza privilegi e che la mappatura UID / GID sia il problema, dai un'occhiata a questa sezione di un articolo sui mapping di Userns con LXD. Tuttavia, questo è stato probabilmente aggiunto a LXD dopo che hai posto la tua domanda.
0xC0000022L

Non so quale versione abbia aggiunto questo (sono su 2.18) ma se possibile, puoi anche usare il lxc fileper trasferire file tra host e container, usando pushe pull.
code_dredd

Risposte:


21

Le istruzioni su https://wiki.gentoo.org/wiki/LXD menzionate sono corrette ma potrebbero essere necessarie ulteriori spiegazioni.

Sull'host si controlla innanzitutto la proprietà della directory in cui sono archiviati i dati del contenitore. Correre

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

e controlla il proprietario del contenitore con cui desideri condividere la directory. Nel mio caso entrambi uided giderano 100000.

Quindi, utilizzali per modificare la proprietà della directory che desideri condividere:

sudo chown 100000:100000 /tmp/share_on_host

Condividi la directory con il contenitore come indicato nel tuo commento:

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

Ora, nel contenitore, vedrai che la directory /tmp/share_on_guest(non consiglierei di montare la tua directory /tmpperché è usata dal sistema per altre cose e ha autorizzazioni speciali) è di proprietà di root. Da qui in poi è possibile utilizzare chownnel contenitore per modificare la proprietà in modo appropriato uide gidper l'utente nel contenitore.

Come nota a margine, dopo aver cambiato la proprietà nel contenitore, ad esempio un utente con uid33, vedrai sull'host che uidora c'è 100033, il che ha perfettamente senso.


Non sono sicuro che si tratti solo della mia configurazione, ma con LXD v3.0.3 LTS (Ubuntu 18.04 LTS) non ho trovato altro che collegamenti simbolici all'interno di /var/lib/lxd/containersquello indicato /var/lib/lxd/storage-pools/lxd/containers(in questo caso l'ultimo lxdbit è il nome del mio pool di archiviazione ZFS). Tutti i container lì sembravano avere lo stesso 165536 uid / gid durante il funzionamento e di proprietà root:rootquando spento.
Deoren

1
Mi rendo conto che questa è una vecchia domanda + risposta, ma in Ubuntu 18.04, non ho dovuto rovinare alcun permesso. Basta aggiungere la cartella con lxc confige ha funzionato come un fascino!
Apache,

4

Ecco una risposta aggiornata a questa domanda.

Montare la cartella host /var/wwwcome /var/testnel contenitore.

lxc config device add mycontainer vartest disk source=/var/www path=/var/test

Benvenuto in Ask Ubuntu! Raccomando di modificare questa risposta per espanderla con dettagli specifici su come eseguire questa operazione. (Vedi anche Come posso scrivere una buona risposta? Per consigli generali su quali tipi di risposte sono considerate più preziose su AskUbuntu.)
David Foerster,

3

È possibile assegnare ulteriori dispositivi al contenitore e questi possono essere cartelle accessibili all'host.

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

Si noti che <device>è solo un nome arbitrario assegnato, che verrà utilizzato come ID per la successiva gestione del dispositivo.

Ad esempio, per montare la cartella host "./host" come "/ mnt / host" nel contenitore ...

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

Rimane un problema : se si desidera che questa cartella sia scrivibile sia dall'host che dal contenitore, la proprietà e le autorizzazioni devono essere configurate di conseguenza. Ciò è complicato dalla modalità predefinita di LXD che virtualizza gli intervalli numerici per i idvalori utente e di gruppo . C'è una soluzione semplice, tuttavia : bypassare questa virtualizzazione configurando il contenitore per l'esecuzione con privilegi equivalenti all'host ...

lxc config set <container> security.privileged true

Le implicazioni complete sulla sicurezza dell'host di questo approccio non mi sono chiare in questo momento, ma sembrerebbero in qualche modo "contenute" dalla virtualizzazione. Il rischio pratico dipende da come e perché verrà utilizzato il contenitore. Vedi le note tecniche su https://insights.ubuntu.com/2017/06/15/custom-user-mappings-in-lxd-containers

Si noti inoltre che questo approccio probabilmente funziona meglio se si opera normalmente nel contenitore come utente non root, ad esempio se si collega con ...

lxc exec zesty -- su --login ubuntu

C'è un problema con il login non root: envè diverso, in particolare http_proxy. Un esempio Soluzione: sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
nobar,

Per quanto riguarda http_proxy, penso che la soluzione più semplice sia probabilmente quella di abilitare IPV4 come discusso qui .
nobar,

... seguito da sudo dhclientnel contenitore - o passare manuala dhcpin 50-cloud-init.cfg. Bei indizi qui: github.com/lxc/lxd/issues/1298
nobar

1
Questa è una cattiva idea. La raccomandazione di passare a contenitori privilegiati sovverte uno dei progressi apportati da LXD. Mentre LXC 1.x offriva anche la possibilità di utilizzare contenitori non privilegiati (e sì, anche come root), era un po 'più complicato ordinare i dettagli. Con LXD questo è ormai un ricordo del passato. Inoltre, cosa c'è di così complicato nell'impostare ACL su alcune cartelle per consentire all'UID lato host l'accesso richiesto o usare il metodo descritto qui ? Sì, la mappatura di UID / GID non è l'unico modo!
0xC0000022L

1

Basato sull'ottima risposta di ph0t0nix , propongo il seguente approccio passo-passo per il mio server Ubuntu 18.04:

  1. Nell'host determinare l'UID del proprietario di rootfs:

    sudo ls -l /var/lib/lxd/storage-pools/lxd/containers/webserver/rootfs  
    id -u root    100000
  2. Nel container determinare l'UID di ubuntu (cioè l'utente nel container):

    id -u ubuntu    1000
  3. Crea una cartella condivisa nell'host e aggiungila al contenitore:

    lxc config device add webserver mydevicename disk path=/home/share_on_guest source=/home/share_on_host
  4. Modifica UID host della cartella condivisa (UID = host UID + guest UID):

    sudo chown 101000:101000 /home/share_on_host
  5. L'ospite (ubuntu utente) ora ha accesso alla cartella condivisa e può adattare all'interno del contenitore l'accesso alla cartella condivisa tramite chmod.


0

Ora ho una soluzione funzionante e sicura a questo problema, usando i profili LXD per gestire il mapping tra UID e GID nel contenitore e nell'host.

Una sintesi molto utile può essere trovata qui:

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


5
Nota che rendere le cose scrivibili dal mondo è di solito una cattiva idea dal punto di vista della sicurezza. Probabilmente dovresti esaminare l'utilizzo di ACL POSIX sul percorso host, concedere l'accesso all'utente del contenitore aggiungendo un ACL specifico per quell'uid e quindi per qualsiasi altro utente host che necessiti anche dell'accesso in scrittura.
incisore il

1
@stgraber mentre sono d'accordo con quello che hai detto, non ho idea di come configurarlo. Alcuni link sarebbero utili.
s3v3n,

Si prega di non raccomandare 0777aka autorizzazioni "per favore-hack-my-system-and-destroy-my-data" senza motivo apparente! Non c'è quasi mai motivo di farlo perché può essere evitato con modifiche più sensate come cambiare la proprietà (del gruppo). -1
David Foerster,

Prendo il tuo punto, ma l'ho usato solo come soluzione temporanea su una macchina di sviluppo per singolo utente, in assenza di altri modi per farlo funzionare. Da allora ho scoperto che usare i profili è il modo di gestirlo, vedi la mia risposta modificata sopra!
user47227,

1
Cosa c'è di così difficile nell'utilizzare ACL o il metodo descritto qui ?
0xC0000022L
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.