systemd-nspawn, systemd-container

[smutbert]

Hi,

vom Prinzip her gefällt mir (glaube ich) systemd-nspawn (systemd-container) sehr gut, aber es will nicht so recht funktionieren, zumindest nicht vollständig. Die Installation mit debootstrap ist ein Kinderspiel, auch das „chrooten“ mit »systemd-nspawn -D /mnt/nextcloud« funktioniert noch, aber wenn ich dann den container richtig starten will, also

Code: Alles auswählen

nspawn -bD /mnt/nextcloud

dann sehe ich zwar die Startmeldungen und darauf folgend den Loginprompt, aber ich kann mich nicht anmelden, obwohl ich ein Passwort gesetzt habe

Code: Alles auswählen

Debian GNU/Linux 10 nextcloud console

nextcloud login: root

Login incorrect
nextcloud login: 
Login timed out after 60 seconds.

Das login incorrect erscheint mit etwas Verzögerung (keine Rede von 60 Sekunden, ich würde sagen es sind so etwa 5 Sekunden) ohne dass er nach einem Passwort fragen würde.

Ich habe mich so etwa an diesen Blog [1] gehalten, aber im Grunde bin ich mit dem was da vorkommt ja sowieso schon von debootstrap und chroot her vertraut, aber ich finde keinen Anhaltspunkt woran das Verhalten liegt. Im Log des Hosts taucht jedenfalls gar keine Meldung auf.

[1] https://www.debinux.de/2015/01/nspawn-a ... erstellen/

(Dabei will ich doch nur nextcloud ausprobieren ohne es auf dem Host installieren zu müssen...)
(Es ist zwar vielleicht keine Grundsatzfrage, aber ich habe kein passenderes Unterforum gefunden.)


noch eine Ergänzung:
Wenn ich auf Umwegen einen normalen Benutzer mit Passwort im Container anlege, dann kann ich mich als dieser Benutzer anmelden, aber auch mit su komme ich nicht weiter (das folgende passiert im Container)

Code: Alles auswählen

$ su
Password: 
su: cannot set groups: Operation not permitted

Ich glaube zwar nicht, dass es eine Rolle spielt, aber /mnt/nextcloud ist ein btrfs subvolume. Außerdem sind sowohl Host wie auch Container schlanke buster-Installationen und ich habe gerade einen Weg gefunden wie ich doch zu einer Shell im Container komme:

Code: Alles auswählen

# systemd-nspawn -bD /mnt/nextcloud
# machinectl shell root@nextcloud /bin/bash
Connected to machine nextcloud. Press ^] three times within 1s to exit session.
root@nextcloud:~#

Einen Workaround hätte ich also schon einmal, aber es wäre doch schön, wenn es auch auf normalen Wege funktionieren würde.

[smutbert]

Möglicherweise habe ich eine Spur. Ich hab mein Vorgehen mit dem von @TomL verglichen und der einzige Unterschied ist, dass TomL bei seiner Schilderung den Container unterhalb von /tmp (vermutlich auf einem tmpfs) anlegt. Auch das habe probiert und erwartungsgemäß hat das nichts am Verhalten geändert.
Mit dem im ersten Beitrag geschilderten Workaround komme ich immerhin zu einer Shell und dort stoße ich gleich auf zwei Dienste des Containers, die beim Start scheitern

systemd-update-utmp.service:

Code: Alles auswählen

root@nextcloud:~# systemctl status systemd-update-utmp.service
● systemd-update-utmp.service - Update UTMP about System Boot/Shutdown
     Loaded: loaded (/lib/systemd/system/systemd-update-utmp.service; static; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2020-01-27 09:35:15 CET; 33s ago
       Docs: man:systemd-update-utmp.service(8)
             man:utmp(5)
    Process: 37 ExecStart=/lib/systemd/systemd-update-utmp reboot (code=exited, status=1/FAILURE)
   Main PID: 37 (code=exited, status=1/FAILURE)

Jan 27 09:35:15 nextcloud systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Jan 27 09:35:15 nextcloud systemd-update-utmp[37]: Failed to write utmp record: Permission denied
Jan 27 09:35:15 nextcloud systemd[1]: systemd-update-utmp.service: Main process exited, code=exited, status=1/FAILURE
Jan 27 09:35:15 nextcloud systemd[1]: systemd-update-utmp.service: Failed with result 'exit-code'.
Jan 27 09:35:15 nextcloud systemd[1]: Failed to start Update UTMP about System Boot/Shutdown.

systemd-logind.service:

Code: Alles auswählen

root@nextcloud:/var# systemctl status systemd-logind.service
● systemd-logind.service - Login Service
     Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2020-01-27 09:35:15 CET; 1h 18min ago
       Docs: man:systemd-logind.service(8)
             man:logind.conf(5)
             https://www.freedesktop.org/wiki/Software/systemd/logind
             https://www.freedesktop.org/wiki/Software/systemd/multiseat
    Process: 98 ExecStartPre=/sbin/modprobe -abq drm (code=exited, status=238/STATE_DIRECTORY)
    Process: 102 ExecStart=/lib/systemd/systemd-logind (code=exited, status=238/STATE_DIRECTORY)
   Main PID: 102 (code=exited, status=238/STATE_DIRECTORY)

Jan 27 09:35:15 nextcloud systemd[1]: Failed to start Login Service.
Jan 27 09:35:15 nextcloud systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 5.
Jan 27 09:35:15 nextcloud systemd[1]: Stopped Login Service.
Jan 27 09:35:15 nextcloud systemd[1]: systemd-logind.service: Start request repeated too quickly.
Jan 27 09:35:15 nextcloud systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Jan 27 09:35:15 nextcloud systemd[1]: Failed to start Login Service.
Jan 27 09:35:18 nextcloud systemd[1]: systemd-logind.service: Start request repeated too quickly.
Jan 27 09:35:18 nextcloud systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Jan 27 09:35:18 nextcloud systemd[1]: Failed to start Login Service.

Vorausgesetzt der „utmp record“ ist »/var/run/utmp« sehe ich im laufenden Container aber keine Auffälligkeiten die den Fehler erklären würden.

Wegen des Vergleichs mit TomL vermute ich, dass es etwas mit der Konfiguration des Hosts zu tun hat, aber ich habe keine Idee wie oder ob die Vermutung zu dem utmp-Fehler passt.

[TomL]

Mir fällt gerade noch eine bei mir vorhandene Rahmenbedingung ein... ich habe keine Ahnung, obs dabei zu Deinem Setup einen Zusammenhang gibt, aber möglicherweise isses ein brauchbarer Hinweis für eine weitere Perspektive.

Bei mir ist ja primär alles mit "noexec" reguliert, also auch /home, /tmp, /dev/shm, alle Share-Dirs. Und weil ich ja, wie Du schon bemerkt hast, für den Container tmpfs nutze, gibts bei mir das Verzeichnis "/testbin", um dort eine solche VM ausführbar starten zu können. Das 'tmpfs' wird allerdings zuvor gemountet:

Code: Alles auswählen

$ cat /etc/systemd/system/testbin.mount
[Unit]
Description=thlu: Mount Local /testbin to tmpfs
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target

[Mount]
What=tmpfs
Where=/testbin
Options=mode=1777,strictatime
Type=tmpfs
 
[Install]
WantedBy=local-fs.target

[smutbert]

Das ist es leider auch nicht, ich habe extra ein tmpfs ohne noexec usw. gemountet und darin den Container erstellt.

Meine Spur hat auch zu nichts geführt. Mit den vielen unterschiedlichen Arten in den container zu „chrooten“ bzw. ihn zu starten habe ich mir die Dateieigentümer und -Gruppenzugehörigen im Container durcheinander gebracht, was zu den oben geschilderten Fehlern geführt hat.
Aktuell kann ich die Container problemlos machinectl starten, auch eine Shell im Container starten, aber der Login funktioniert wie eingangs beschrieben mit dem gleichen Fehlerbild immer noch nicht.

[smutbert]

Vergesst meine bisherigen Log-Auszüge und Schilderungen. Das waren alles andere Probleme, die ihren Ursprung in meiner Ahnungslosigkeit was Container angeht, haben.

Jetzt sehe ich im Log des Containers woran es scheitert:

Code: Alles auswählen

Jan 29 10:03:12 nextcloud login[242]: pam_securetty(login:auth): access denied: tty '/dev/pts/2' is not secure !
Jan 29 10:03:14 nextcloud login[242]: FAILED LOGIN (1) on '/dev/pts/2' FOR 'root', Authentication failure

pam hält also die Konsole für unsicher, wenn ich das recht verstehe. Ich könnte das wohl irgendwie durch Anpassen der »/etc/securetty« hinbiegen, aber nachdem ich den Login-Bildschirm ja nicht unbedingt brauche, ist es mir sogar lieber, wenn das pam des Containers übervorsichtig ist.

Trotzdem würde ich mich über weitere sachdienliche Hinweise freuen. Im Netz habe ich zwar Berichte über die ähnliche Probleme gefunden, aber immer mit leicht anderen Ursachen.

[TomL]

Moin Smutbert

Leider habe ich keine Idee mehr und kann deswegen auch nicht helfen... aber das schützt ja nicht vor Neugier So mal rückblickend betrachtet glaube ich, dass ich wohl schon 100 Mal oder mehr so einen Container erfolgreich eingerichtet habe... gerade in tmpfs geht das ja rasend schnell... eben mal schnell was testen, oder kompilieren... und wieder weg damit. Ich mach das immer im aktuellen Stable und der Container ist natürlich dann auch ein Stable. Das Filesystem auf meinem Desktop ist ext4.... hinsichtlich laufender Dienste ist hier alles nach dem Sparsamkeits-Prinzip eingerichtet. Es hat bisher nicht ein einziges Mal Probleme mit so einem Neu-Setup gegeben. Insofern interessiert mich schon, ob vielleicht (und welche) Unterschiede da bestehen, also z.B. OS, Release, FS....?

Das muss ja einen Grund haben, dass PAM mit irgendwas nicht einverstanden ist..... .... BTW, was issen das für eine Konsole? Ich kann rückblickend sagen, dass es hier mit lxterminal, xterm und urxvt keine Probleme gab.

[smutbert]

Der Fehler tritt mit dem Gnome-Terminal genauso auf wie auf einer echten Textkonsole.