contenitore Userns non si avvia, come rintracciare il motivo?


8

Quando si crea un contenitore LXC userns (senza privilegi) su Ubuntu 14.04 con la seguente riga di comando:

lxc-create -n test1 -t download -- -d $(lsb_release -si|tr 'A-Z' 'a-z') -r $(lsb_release -sc) -a $(dpkg --print-architecture)

e (senza toccare il file di configurazione creato) quindi tentando di avviarlo con:

lxc-start -n test1 -l DEBUG

fallisce. Il file di registro mi mostra:

lxc-start 1420149317.700 INFO     lxc_start_ui - using rcfile /home/user/.local/share/lxc/test1/config
lxc-start 1420149317.700 INFO     lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1420149317.701 INFO     lxc_confile - read uid map: type u nsid 0 hostid 100000 range 65536
lxc-start 1420149317.701 INFO     lxc_confile - read uid map: type g nsid 0 hostid 100000 range 65536
lxc-start 1420149317.701 WARN     lxc_log - lxc_log_init called with log already initialized
lxc-start 1420149317.701 INFO     lxc_lsm - LSM security driver AppArmor
lxc-start 1420149317.701 INFO     lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1420149317.702 DEBUG    lxc_conf - allocated pty '/dev/pts/2' (5/6)
lxc-start 1420149317.702 DEBUG    lxc_conf - allocated pty '/dev/pts/7' (7/8)
lxc-start 1420149317.702 DEBUG    lxc_conf - allocated pty '/dev/pts/8' (9/10)
lxc-start 1420149317.702 DEBUG    lxc_conf - allocated pty '/dev/pts/10' (11/12)
lxc-start 1420149317.702 INFO     lxc_conf - tty's configured
lxc-start 1420149317.702 DEBUG    lxc_start - sigchild handler set
lxc-start 1420149317.702 DEBUG    lxc_console - opening /dev/tty for console peer
lxc-start 1420149317.702 DEBUG    lxc_console - using '/dev/tty' as console
lxc-start 1420149317.702 DEBUG    lxc_console - 14946 got SIGWINCH fd 17
lxc-start 1420149317.702 DEBUG    lxc_console - set winsz dstfd:14 cols:118 rows:61
lxc-start 1420149317.905 INFO     lxc_start - 'test1' is initialized
lxc-start 1420149317.906 DEBUG    lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1420149317.906 INFO     lxc_start - Cloning a new user namespace
lxc-start 1420149317.906 INFO     lxc_cgroup - cgroup driver cgmanager initing for test1
lxc-start 1420149317.907 ERROR    lxc_cgmanager - call to cgmanager_create_sync failed: invalid request
lxc-start 1420149317.907 ERROR    lxc_cgmanager - Failed to create hugetlb:test1
lxc-start 1420149317.907 ERROR    lxc_cgmanager - Error creating cgroup hugetlb:test1
lxc-start 1420149317.907 INFO     lxc_cgmanager - cgroup removal attempt: hugetlb:test1 did not exist
lxc-start 1420149317.908 INFO     lxc_cgmanager - cgroup removal attempt: perf_event:test1 did not exist
lxc-start 1420149317.908 INFO     lxc_cgmanager - cgroup removal attempt: blkio:test1 did not exist
lxc-start 1420149317.908 INFO     lxc_cgmanager - cgroup removal attempt: freezer:test1 did not exist
lxc-start 1420149317.909 INFO     lxc_cgmanager - cgroup removal attempt: devices:test1 did not exist
lxc-start 1420149317.909 INFO     lxc_cgmanager - cgroup removal attempt: memory:test1 did not exist
lxc-start 1420149317.909 INFO     lxc_cgmanager - cgroup removal attempt: cpuacct:test1 did not exist
lxc-start 1420149317.909 INFO     lxc_cgmanager - cgroup removal attempt: cpu:test1 did not exist
lxc-start 1420149317.910 INFO     lxc_cgmanager - cgroup removal attempt: cpuset:test1 did not exist
lxc-start 1420149317.910 INFO     lxc_cgmanager - cgroup removal attempt: name=systemd:test1 did not exist
lxc-start 1420149317.910 ERROR    lxc_start - failed creating cgroups
lxc-start 1420149317.910 INFO     lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1420149317.910 ERROR    lxc_start - failed to spawn 'test1'
lxc-start 1420149317.910 INFO     lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1420149317.910 INFO     lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1420149317.910 ERROR    lxc_start_ui - The container failed to start.
lxc-start 1420149317.910 ERROR    lxc_start_ui - Additional information can be obtained by setting the --logfile and --logpriority options.

Ora vedo due errori qui, quest'ultimo probabilmente è il risultato del primo, che è:

lxc_start - la creazione dei cgroup non è riuscita

Tuttavia, vedo /sys/fs/cgroupmontato:

$ mount|grep cgr
none on /sys/fs/cgroup type tmpfs (rw)

ed cgmanagerè installato:

$ dpkg -l|awk '$1 ~ /^ii$/ && /cgmanager/ {print $2 " " $3 " " $4}'
cgmanager 0.24-0ubuntu7 amd64
libcgmanager0:amd64 0.24-0ubuntu7 amd64

Nota: l'impostazione predefinita del mio host è ancora upstart.

In caso di dubbi, il supporto del kernel cgroups:

$ grep CGROUP /boot/config-$(uname -r)
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_NET_CLS_CGROUP=m
CONFIG_NETPRIO_CGROUP=m

Nota: l'impostazione predefinita del mio host è ancora upstart.

Risposte:


7

Si scopre, sorpresa sorpresa, questa è una cosa specifica di Ubuntu.


La causa

Il problema: sebbene il kernel abbia cgroupsabilitato (controlla con grep CGROUP /boot/config-$(uname -r)) ed cgmanagerè in esecuzione, non esiste un cgroup specifico per il mio utente. Puoi verificarlo con:

$ cat / proc / self / cgroup
11: hugetlb: /
10: perf_event: /
9: blkio: /
8: congelatore: /
7: dispositivi: /
6: Memoria: /
5: cpuacct: /
4: CPU: /
3: name = systemd: /
2: cpuset: /

se il tuo UID è indicato in ciascuna delle righe pertinenti, va bene, ma se non sono stati definiti cgroups ci sarà solo una barra dopo i due due punti su ogni riga.

Il mio problema era specifico dell'avvio di un contenitore senza privilegi. Potrei iniziare bene i container privilegiati.

Si è scoperto che il mio problema era strettamente correlato a questo thread nella lxc-usersmailing list .

Rimedio

Su Ubuntu 14.04 upstartè l'impostazione predefinita, al contrario di systemd. Pertanto alcuni componenti che verrebbero installati su una systemddistribuzione basata su base non vengono installati per impostazione predefinita.

C'erano due pacchetti in aggiunta ai cgmanagerquali dovevo installare per superare l'errore mostrato nella mia domanda: cgroup-bine libpam-systemd. Francamente non sono sicuro al 100% che il primo sia strettamente necessario, quindi potresti provare a lasciarlo fuori e commentare qui.

Dopo l'installazione dei pacchetti e un riavvio, dovresti vedere il tuo UID ( id -u, qui 1000) nell'output:

$ cat / proc / self / cgroup
11: hugetlb: /user/1000.user/1.session
10: perf_event: /user/1000.user/1.session
9: blkio: /user/1000.user/1.session
8: congelatore: /user/1000.user/1.session
7: dispositivi: /user/1000.user/1.session
6: Memoria: /user/1000.user/1.session
5: cpuacct: /user/1000.user/1.session
4: CPU: /user/1000.user/1.session
3: name = systemd: /user/1000.user/1.session
2: cpuset: /user/1000.user/1.session

Successivamente, l'errore nel tentativo di avviare il contenitore guest diventa (tagliato per brevità):

lxc-start 1420160065.383 INFO lxc_cgroup - driver cgroup cgmanager initing per test1
lxc-start 1420160065.419 ERRORE lxc_start - impossibile creare la rete configurata
lxc-start 1420160065.446 ERRORE lxc_start - impossibile generare 'test1'
lxc-start 1420160065.451 ERRORE lxc_start_ui - Impossibile avviare il contenitore.

Quindi ancora nessun successo, ma siamo un passo avanti.

I sopra legate lxc-userspunti filettatura per /etc/systemd/logind.confnon menzionare tre controller: net_cls, net_prioe debug. Per me mancava solo l'ultimo. Dopo la modifica, dovrai effettuare nuovamente l'accesso, poiché le modifiche avranno effetto al momento della creazione della sessione di accesso.

Questo post sul blog di uno degli autori di LXC fornisce il passaggio successivo:

Il tuo utente, mentre può creare nuovi spazi dei nomi utente in cui sarà uid 0 e avrà alcuni dei privilegi di root rispetto alle risorse legate a quello spazio dei nomi, ovviamente non gli verrà concesso alcun privilegio aggiuntivo sull'host.

Una cosa del genere è la creazione di nuovi dispositivi di rete sull'host o la modifica della configurazione del bridge. Per ovviare a questo, abbiamo scritto uno strumento chiamato "lxc-user-nic" che è l'unica parte binaria SETUID di LXC 1.0 e che esegue un semplice compito. Analizza un file di configurazione e in base al suo contenuto creerà dispositivi di rete per l'utente e li collegherà. Per prevenire abusi, è possibile limitare il numero di dispositivi che un utente può richiedere e a quale bridge possono essere aggiunti.

Un esempio è il mio file / etc / lxc / lxc-usernet:

stgraber veth lxcbr0 10

Questo dichiara che l'utente "stgraber" può creare e aggiungere fino a 10 dispositivi di tipo veth al bridge chiamato lxcbr0.

Tra ciò che viene offerto dallo spazio dei nomi utente nel kernel e quello strumento setuid, abbiamo tutto ciò che è necessario per eseguire la maggior parte delle distribuzioni senza privilegi.

Se il tuo utente ha sudodiritti e stai usando Bash, usa questo:

echo "$(whoami) veth lxcbr0 10"|sudo tee -a /etc/lxc/lxc-usernet

e assicurati che type ( veth) corrisponda a quello nella configurazione del container e che bridge ( lxcbr0) sia configurato e attivo.

E ora otteniamo un altro set di errori:

lxc-start 1420192192.775 INFO lxc_start - Clonazione di un nuovo spazio dei nomi utente
lxc-start 1420192192.775 INFO lxc_cgroup - driver cgroup cgmanager initing per test1
lxc-start 1420192192.923 AVVISO lxc_start - passaggio a gid / uid 0 nel nuovo spazio dei nomi utente
lxc-start 1420192192.923 ERRORE lxc_start - Autorizzazione negata - impossibile accedere a / home / user. Concedi l'accesso "x" o aggiungi un ACL per la radice del contenitore.
lxc-start 1420192192.923 ERRORE lxc_sync - numero progressivo non valido 1. previsto 2
lxc-start 1420192192.954 ERRORE lxc_start - impossibile generare 'test1'
lxc-start 1420192192.959 ERRORE lxc_start_ui - Impossibile avviare il contenitore.

Fantastico, che può essere risolto. Un altro lxc-usersthread degli stessi protagonisti del primo thread apre la strada.

Per ora sudo chmod -R o+X $HOMEdovrà essere eseguito un test rapido , ma anche le ACL sono un'opzione praticabile. YMMV.


Sono ancora bloccato dal fatto che se voglio eseguire il container LXC userns come un altro utente, non riesce. La creazione funziona (con un avvertimento:) WARN: could not reopen tty: Permission denied. Ma l'avvio sudo -H -i -u database lxc-start -n mysql -dnon riesce come nella tua domanda. Stessi errori. Tuttavia, la correzione non funziona sudo. Se lo faccio sudo -H -i -u database cat /proc/self/cgroupottengo lo stesso identico output che se lo eseguo come utente chiamante. Quindi, ovviamente, quando provo ad avviare il contenitore usando sudo, proverà come l'altro utente a scrivere nel mio cgroup che non riesce ... :-( Qualche intuizione?
Huygens,
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.