Moby: Fuse kann nicht innerhalb eines Containers verwendet werden

Es sollte sofort funktionieren, vorausgesetzt, Sie kommentieren die entsprechende Zeile in lxc-template.go aus :-)

Wissen Sie zufällig aus dem Kopf, welche Funktion aktiviert werden muss und ob dies sicher ist?

Es ist ein Mount, also brauchen Sie CAP_SYS_ADMIN.
Es ist sicher, es zu tun.
IMHO sollte es eine Art Flag geben, um zwischen dem eingeschränkten Modus zu wechseln
(paranoid, keine Obergrenzen) und vertrauenswürdiger Modus (ermöglicht einige nützliche Obergrenzen, ermöglicht
FUSE, Docker-in-Docker und andere Dinge).

Hallo, meine Herren.

Ich versuche, Gluster aus einem Docker-Image zu verwenden und bekomme:

[2013-06-12 08:59:06.191225] E [mount.c:598:gf_fuse_mount] 0-glusterfs-fuse: /dev/fuse kann nicht geöffnet werden (keine solche Datei oder Verzeichnis)

Wenn ich es richtig verstehe, sieht es so aus, als müsste ich etwas im Quellcode auskommentieren und vielleicht neu kompilieren? Entschuldigung für die Anfängerfrage, aber ich bin ein Systemadministrator und kein Entwickler. ;)

Hallo Eri, ja, standardmäßig sperrt Docker die Berechtigungen von Containern auf ein Minimum - insbesondere sind die Gerätedateien des Hosts nicht zugänglich.

Dies kann geändert werden, indem lxc_template.go angepasst und neu kompiliert wird. Wir planen, diese Art der Optimierung dynamisch zuzulassen (fühlen Sie sich frei, eine PR zu machen, wenn Sie inspiriert sind!)
—
@solomonstr
@getdocker

Am Mittwoch, 12. Juni 2013 um 6:21 Uhr, Eri Bastos [email protected]
schrieb:

Hallo, meine Herren.
Ich versuche, Gluster aus einem Docker-Image zu verwenden und bekomme:
[2013-06-12 08:59:06.191225] E [mount.c:598:gf_fuse_mount] 0-glusterfs-fuse: /dev/fuse kann nicht geöffnet werden (keine solche Datei oder Verzeichnis)

Wenn ich es richtig verstehe, sieht es so aus, als müsste ich etwas im Quellcode auskommentieren und vielleicht neu kompilieren? Entschuldigung für die Anfängerfrage, aber ich bin ein Systemadministrator und kein Entwickler. ;)

Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/dotcloud/docker/issues/514#issuecomment -19324759

Speziell,. Sie müssen lxc.cgroup.devices.allow = c 10:229 rwm [1] auskommentieren, um den Zugriff auf das FUSE-Gerät zu ermöglichen; und dann müssen Sie mknod und sys_admin aus der Zeile lxc.cap.drop entfernen. Dann sollte alles in Ordnung sein.

[1] https://github.com/dotcloud/docker/blob/master/lxc_template.go#L63
[2] https://github.com/dotcloud/docker/blob/master/lxc_template.go#L89

Ich denke, was ich in #460 versuche, wird in diesem Anwendungsfall helfen, weil Sie die LXC-Vorlage dynamisch ändern können .... außer .... was macht LXC, wenn eine Direktive zweimal aufgeführt ist? Nur den letzten verwenden?

Wenn es nicht vorhersehbar ist (oder Fehler verursacht), müsste der Patch in #460 geändert werden, um das Vorhandensein einer JSON-konfigurierten lxc.cap.drop (oder einer anderen Direktive) zu erkennen und diese stattdessen einzufügen.

Dies ist möglich, indem die lxc-Einschränkungen manuell gelockert werden, entweder einzeln oder insgesamt mit einem "privilegierten Modus", wie oben beschrieben. In der Zwischenzeit ist das aktuelle Standardverhalten aus Sicherheitsgründen korrekt.

Ich bin verwirrt, ob es möglich ist, die Beschränkungen jetzt zu lockern, um FUSE zu verwenden. Ich würde vorschlagen, dieses Ticket offen zu lassen, bis dies der Fall ist.

Als Problemumgehung für den Fall, dass Ihre Pakete die Installation von Fuse erfordern, es aber nicht tatsächlich verwenden, reicht es aus, Fuse zu installieren, ohne seine Geräteverknüpfungen zu erstellen. Ein kurzes Snippet zum Einfügen in Ihr Dockerfile finden Sie hier: https://gist.github.com/henrik-muehe/6155333

Ich habe basex (das jdk und damit eine Sicherung als Abhängigkeit hat) auf diese Weise erfolgreich installiert und es funktioniert bei mir.

Hallo,

An das Docker-Team – was ist die langfristige Lösung für dieses Problem?

Ich stoße derzeit auf dieses Problem, wenn ich versuche, openjdk-7-jdk zu installieren, wodurch die Sicherung gezogen wird.

Die Verwendung von @henrik-muehe Workaround funktioniert, aber es wäre schön, wenn es eine dauerhaftere Lösung oder eine offizielle Lösung gäbe?

Prost,
Sieger

„docker build“ unterstützt die erforderlichen Operationen (nämlich mknod).
Wenn Sie etwas Code beitragen möchten, ist der einfachste Weg dorthin #2191 :-)

+1

@jpetazzo , "docker build" leidet unter demselben Problem
Docker-Version 0.6.7, Build cb48ecc

Übrigens, @henrik-muehe Workaround funktioniert wie ein Zauber, danke Henrik!

Wenn Sie die Gerätedatei nicht wirklich verwenden (aber sie ist nur Teil eines Post-Inst-Skripts wie im Fall des Sicherungspakets), können Sie Folgendes tun:

fakeroot apt-get ... 

oder:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

Docker 0.7 schnelle Lösung

docker run -i -t -privileged=true your/image /bin/bash

dpkg-divert ist eine gefährliche Sache, es immer häufiger in vagabundierenden Dateien zu sehen, macht mich sehr besorgt.

Es ist besser, das Täterpaket zu reparieren, um es zur Buildzeit zu patchen, um nicht auf die blockierte Ressource zuzugreifen.
Dann teilen Sie dpkg mit, es nicht mehr zu aktualisieren.

Take an exemple for our vagrantfiles eg:
    FROZEN_PACKAGES="fuse"
    for i in $FROZEN_PACKAGES;do\
      echo $i hold | dpkg --set-selections;\
    done&&\
    grep "deb " /etc/apt/sources.list|sed -re "s/^deb /deb-src /g" >> /etc/apt/sources.list &&\
    apt-get -q update && apt-get upgrade -y --force-yes &&\
    apt-get install -y --force-yes libfuse2 apt-utils &&\
    if [ ! -e "/root/debbuild" ];then mkdir -pv /root/debbuild;fi &&\
    mv /root/ntp_postinst /root/debbuild &&\
    cd /root/debbuild;\
    nf=/etc/network/interfaces;
    for i in fuse;do \
      mkdir -p $i && cd $i &&\
      apt-get download -y $i &&\
      dpkg-deb -X $i*deb build &&\
      dpkg-deb -e $i*deb build/DEBIAN && \
      rm *deb && cd ..;done &&\
    cp /root/debbuild/ntp_postinst /root/debbuild/ntp/build/DEBIAN/postinst &&\
    echo "#!/bin/bash"   >/root/debbuild/resolvconf/build/DEBIAN/postinst &&\
    echo "exit 0"       >>/root/debbuild/resolvconf/build/DEBIAN/postinst &&\
    echo ""             >>/root/debbuild/resolvconf/build/DEBIAN/postinst &&\
    echo "#!/bin/bash"   >/root/debbuild/fuse/build/DEBIAN/postinst &&\
    echo "#exit 0"      >>/root/debbuild/fuse/build/DEBIAN/postinst &&\
    echo ""             >>/root/debbuild/fuse/build/DEBIAN/postinst &&\
    for i in fuse;do\
      cd /root/debbuild/$i/build&&\
      dpkg-deb -b . /root/debbuild/$i.deb;\
    done&&\
    for i in fuse;do\
      dpkg -i /root/debbuild/$i.deb&&\
      echo $i hold | dpkg --set-selections;\
    done

Echtes Beispiel hier: ps://github.com/makinacorpus/vms/blob/master/docker/makinacorpus/ubuntu_template/

Ich bekomme immer diesen Fehler. das ist meine ~/.config/lxc/default.conf:
lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.flags = hoch
lxc.network.hwaddr = 00:16:3e:xx:xx:xx
lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536

Ich fügte hinzu:
lxc.cgroup.devices.allow = c 10:229 rwm

einen neuen lxc-Container erstellt, erhalte aber weiterhin diesen Fehler:

root@my-container :/# apt-get -y Sicherung installieren
Paketlisten lesen... Fertig
Abhängigkeitsbaum erstellen
Zustandsinformationen lesen... Fertig
Sicherung ist bereits die neuste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach diesem Vorgang werden 0 B zusätzlicher Speicherplatz verwendet.
Sicherung einrichten (2.9.4-1ubuntu1) ...
Sicherungsgerät erstellen...
mknod: 'fuse-': Operation nicht erlaubt
makedev sicherung c 10 229 root root 0660: fehlgeschlagen
chmod: Zugriff auf '/dev/fuse' nicht möglich: Keine solche Datei oder Verzeichnis
dpkg: Fehler bei der Verarbeitung des Pakets fuse (--configure):
Das vom Unterprozess installierte Nachinstallationsskript hat den Fehler-Exit-Status 1 zurückgegeben
Bei der Verarbeitung sind Fehler aufgetreten:
Sicherung
E: Unterprozess /usr/bin/dpkg hat einen Fehlercode zurückgegeben (1)

Ich habe Apparmor deaktiviert, bekomme es aber immer wieder.

Jede Hilfe wäre willkommen.

@yinonby Docker verwendet lxc nicht mehr, also posten Sie Ihre Frage wahrscheinlich am besten dort. Wenn Sie fuse in einem _docker_-Container ausführen möchten, funktioniert dies (siehe Dokumentation );

$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse ubuntu

Dann in den Container

apt-get update && apt-get install -y sshfs

mkdir -p /mnt/droplet
sshfs -o allow_other user<strong i="11">@host</strong>:/ /mnt/droplet

Sie benötigen auch --cap-add MKNOD oder fügen das Sicherungsgerät hinzu.

Am 12. August 2016 1:40 Uhr, „Sebastiaan van Stijn“ [email protected]
schrieb:

@yinonby https://github.com/yinonby Docker verwendet lxc nicht mehr, also
Wahrscheinlich am besten, Ihre Frage dort zu posten. Wenn Sie eine Sicherung in a ausführen möchten
_docker_ Container, das funktioniert (siehe die Dokumentation
https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities
);

$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse ubuntu

Dann in den Container

apt-get update && apt-get install -y sshfs

mkdir -p /mnt/droplet
sshfs -o allow_other user@host :/ /mnt/droplet

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/514#issuecomment -239334271 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAdcPJnT5dszDVd2d66Ju1lx5x8GuWobks5qe8ERgaJpZM4AoQJ6
.