debootstrap nach /var/lib/machines nicht möglich

[scientific]

Hi Leute!

Nachdem mich docker gerade ziemlich nervt, möchte ich mich einer anderen Containertechnik zuwenden. systemd-nspawn.

Da bin ich gleich zu Beginn auf ein Problem gestoßen. Beim Versuch in das Arbeitsverzeichnis für systemd-nspawn zu debootstrappen passiert folgendes:

Code: Alles auswählen

# debootstrap --arch=amd64 stretch /var/lib/machines/container1/
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file http://deb.debian.org/debian/dists/stretch/Release

In diesem Verzeichnis ist dann folgendes:

Code: Alles auswählen

# tree container1/
container1/
├── debootstrap
│   └── debootstrap.log
└── var
    ├── cache
    │   └── apt
    │       └── archives
    │           └── partial
    └── lib
        └── apt
            └── lists
                └── partial

10 directories, 1 file

In diesem Log steht:

Code: Alles auswählen

# cat container1/debootstrap/debootstrap.log 
/var/lib/machines/container1/var/lib/apt/lists/partial/debootstrap.invalid_dists_stretch_InRelease: Read-only file system
/var/lib/machines/container1/var/lib/apt/lists/partial/debootstrap.invalid_dists_stretch_Release: Read-only file system

Das Filesystem ist aber nicht Read-only wie ein kleiner Test zeigt:

Code: Alles auswählen

# touch /var/lib/machines/container1/var/lib/apt/lists/partial/test
( 0 ✓) root@aldebaran (20:27)
[/@debian-testing]/var/lib/machines: # tree
.
└── container1
    ├── debootstrap
    │   └── debootstrap.log
    └── var
        ├── cache
        │   └── apt
        │       └── archives
        │           └── partial
        └── lib
            └── apt
                └── lists
                    └── partial
                        └── test

11 directories, 2 files

Was könnte das debootstrappen in diesem Verzeichnis verhindern? In meinem Home klappt es nämlich tadellos...

lg scientific

[Livingston]

Mal ein Schuss ins Blaue: Ist da vielleicht der neue User "_apt" am Werk, der ohne root-Rechte (noch) nicht dort reinschreiben darf?

[scientific]

Das wär natürlich möglich...
Aber wer da nicht ein Permissionproblem und nicht eine Fehlermeldung wegen Readonly-FS?

[Livingston]

Stimmt auch wieder.
Aber jetzt, wo Du's schreibst, kommt gerade eine Erinnerung aus alten Zeiten wieder zum Vorschein, als ich mit chroot rumexperimentiert habe und innerhalb des Jails einen Zweig neu read-only gemountet hatte. Von außen konnte ich voll zugreifen, innerhalb der chroot-Umgebung galten aber die eingeschränkten Regeln.
Allerdings hängt debootstrap nicht von chroot ab. Hast Du eventuell selbst noch mal mit bind-Optionen oder so was drübergemounted, evtl. gut vor Dir selbst versteckt in einem guten, alten Script?

[scientific]

Solche mounts habe ich nicht.

In folgenden Verzeichnissen kann ich nicht installieren:
/etc
/var
/var/lib
/var/lib/machines

Ich kann installieren in
/opt
/var/www
/var/virtual-machines (hab ich selber mal angelegt)
/var/lib/docker

Dabei bin ich jetzt dahintergekommen, die Verzeichnisse in denen ich debootstrap ausführen kann, sind gemountete btrfs-subvolumes. Dort wo ich nicht installieren kann, ist direkt das btrfs-system-subvolume,

Genauer schaut mein Setup so aus:
Ich habe ein Subvolume auf der BTRFS-Partition, welches @debian-testing heißt. Dieses mounte ich nach /
Dann habe ich ein weiteres Subvolume das nenne ich __ALWAYSCURRENT__, darin befinden sich weitere Subvolumes die z.B. var-www oder var-lib-docker heißen.
Diese werden dann nach /var/www oder /var/lib/docker gemountet.

Das spannende ist, das BTRFS-Root-Verzeichnis (in dem @debian-testing und __ALWAYSCURRENT__ liegen) mounte ich nach /var/cache/btrfs_pool_SYSTEM
Wenn ich dort nach @debian-testing/var/lib/machines gehe - also an den exakt selben Ort wie /var/lib/machines, dann kann ich dort installieren. In /var/lib/machines nicht.

Die Mountoption für das Subvolume auf / sehen so aus:

Code: Alles auswählen

UUID=9081c6de-4a5a-4b85-ac42-f3853e26c048       /                       btrfs   defaults,compress=lzo,nospace_cache,noinode_cache,noatime,ssd,discard

aber das wären doch keine außergewöhnlichen Mountoptionen.
Für /var/www (in das ich ein Subvolume debootstrappen kann sehen so aus:

Code: Alles auswählen

UUID=9081c6de-4a5a-4b85-ac42-f3853e26c048       /var/www                btrfs   defaults,compress=lzo,nospace_cache,noinode_cache,noatime,ssd,discard,subvol=__ALWAYSCURRENT__/var-www

Also bis auf die Angabe des subvols identisch.

Kann es sein, dass mir hier firejail dazwischenfunkt?
Ich habe aber getestet, mount, debootstrap, apt zeigen auf die originalen binaries.
Irgendwie sieht mir das nach eine Capabilitiesgeschichte aus. Oder apparmor... das hab ich hier auch installiert...
Irgendwas unterbindet auf bestimmte Systemverzeichnisse den schreibenden Zugriff. Und zwar nicht als Permission, sondern stellt der Anwendung das Filesystem als Readonly dar...

[scientific]

Ich habs gefunden.
Firejail sperrt mir wget in eine Sandbox ein. Debootstrap ruft wget offenbar mehrfach auf. Die runtergeladenen Dateien (Release...) werden aber nach dem Beenden von wget mit der Sandbox auch gleich wieder verworfen und stehen damit debootstrap nicht mehr zur Verfügung.

Mittels strace bin ich auf den Aufruf von wget bei debootstrap gekommen.
mit firemon sah ich das ebenfalls.

Habe nun /usr/local/bin/wget (ein Symlink auf firejail) gelöscht. Damit wird direkt wget ohne Firejail aufgerufen, und siehe da, ich kann in /var/lib/machines ein neues System debootstrappen.

Jetzt frage ich mich, wie ich /var/lib/machines für wget freigeben kann...

lg scientific