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

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

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

Beitrag von scientific » 07.11.2017 20:30:48

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
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Livingston
Beiträge: 1367
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

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

Beitrag von Livingston » 09.11.2017 14:26:02

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

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

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

Beitrag von scientific » 09.11.2017 19:11:31

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

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Livingston
Beiträge: 1367
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

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

Beitrag von Livingston » 09.11.2017 19:59:24

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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

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

Beitrag von scientific » 09.11.2017 23:01:12

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...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

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

Beitrag von scientific » 09.11.2017 23:43:17

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
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten