Nextcloud: Fileserver über NFS/SFTP

[Rüdiger Kupper]

Siehe ticket:4009:comment:1 ff

Ziel: Home- und Tauschverzeichnis lokal auf dem Nextcloud-Server über NFS mounten wie auf jedem Schulrechner. Dann zur Wahrung der Rechte in Nextcloud als NFS-Share einbinden.

Dazu wird auch eine funktionierende LDAP-Anbindung zur Nutzerauthentifizierung benötigt.

[Rüdiger Kupper]

Ich habe die NFS-Mounts für die fstab von einem anderen Lehrernetzrechner kopiert:

10.16.112.4:/home/students  /home/students               nfs    _netdev,bg             0       0
10.16.112.4:/home/teachers  /home/teachers               nfs    _netdev,bg             0       0
10.16.112.4:/home/share     /home/share                  nfs    _netdev,bg             0       0

Ein mount -a führt aber zur Meldung

mount.nfs: Operation not permitted
mount.nfs: Operation not permitted
mount.nfs: Operation not permitted

Warum? Eigentlich ist der Zugriff für das ganze 10.16.112-Subnetz freigegeben, siehe paedml:/etc/exports:

/nfsexport                      10.32.0.0/12(fsid=0,rw,async,subtree_check,no_root_squash) 10.16.112.0/23(fsid=0,rw,async,subtree_check,no_root_squash)
/nfsexport/home/students        10.32.0.0/12(rw,async,subtree_check,no_root_squash) 10.16.112.0/23(rw,async,subtree_check,no_root_squash) 10.32.1.249(rw,async,subtree_check,no_root_squash)
/nfsexport/home/teachers        10.32.0.0/12(rw,async,subtree_check,no_root_squash) 10.16.112.0/23(rw,async,subtree_check,no_root_squash)
/nfsexport/home/share           10.32.0.0/12(rw,async,subtree_check,no_root_squash) 10.16.112.0/23(rw,async,subtree_check,no_root_squash)

Warum kann ich die NFS-Verzeichnisse nicht mounten?

[Rüdiger Kupper]

Die fstab ist ansonsten leer. Werden die Mounts bei einem lxc-Container woanders eingetragen?

[Rüdiger Kupper]

Müssen die Verzeichnisse auf dem proxmoxls2 gemountet werden und dann an den Container durchgereicht?

[Rüdiger Kupper]

Siehe z.B.:
​https://theorangeone.net/posts/mount-nfs-inside-lxc/

[Rüdiger Kupper]

Und hier:
​https://discuss.linuxcontainers.org/t/nfs-directly-inside-container/9841

Demnach ist der einfache Weg, das NFS auf dem Host zu mounten und dann durchzureichen. Spricht da bei uns etwas dagegen?

[Rüdiger Kupper]

Auf dem proxmoxls2 lassen sich die NFS-Shares pronlemlos mounten, doch ich weiß noch micht, wie ich die dann im den container weitergereicht bekomme.

[bau]

Damit LXC nfs mounten darf, muss es ein privilegierter Container werden, siehe ​https://theorangeone.net/posts/mount-nfs-inside-lxc/

Klar kann man das NFS auch auf dem Host mounten und durchreichen:
​https://steamforge.net/wiki/index.php/How_to_mount_a_Network_Share_in_a_Linux_Container_under_Proxmox

aber besser wäre es, aus einem unprivileged einen privileged Container zu machen, geht aber nur mit einem Backup/Restore:
​https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

[bau]

• Container 101 ist aktuell gestoppt.
• apt-update lief nicht mehr, da die Packages von Debian/Buster ihren Status von stable nach oldstable geändert haben (habe das abgenickt und ein update gemacht)

[Rüdiger Kupper]

Ja, Container ist gestoppt, da ich gestern nocj dir NFS/LDAP-Anbindung machen wollte und dann am NFS gescheitert bin.
Das apt update wollte ich auch schon machen, war dann aber nichr sicher wegen der Meldung zuvden Repositories. Wollte Dir da nicht vorgreifen :-).

Auf dem proxmoxls2 stehen jetzt die NFS-Shares in der fstab. Hat direkt funktioniert und das nfs-common-Paket war bereits installiert. Jetzt haben wir zwei Möglichkeiten:

1. Das Verzeichnis vom proxmoxls2 in den Container durchreichen — was muss man dazu in die Configdatei schreiben?
2. Oder das LDAP ebenfalls auf dem proxmoxls2 anbinden, dann kann der cloud-Rechner die sftp-Verbindung zum peoxmoxls2 machen.

Ist aber etwas unbefriedigend, dass Dienste für die Container direkt auf den Host laufen. Das haben wir uns mit der Wahl von lxc eingehandelt. NFS ist ein Kernel-Dienst und die lassen sich in einem lxc-Container nicht unabhängig konfugurieren. Mit einer vollen VM gäbe es das Problem nicht.

Wir gehen wir da vor?

[Rüdiger Kupper]

Ich überschaue auch die Sache mit "privileged" und "unprivileged" lxc-Containern noch nicht. Wir haben einen unpriviligierten Container. Irgendwie kann man dort dem Nutzer auch erlauben, z.B. Devices einzurichten, da ist aber immer von "veth"-Devices die Rede, die ich nicht kenne. Beim NFS hilft uns das auch nicht weiter, glaube ich.

Die unpriviligierten Container übersetzen z.B. alle UIDs, so dass die Nutzer innerhalb der Container außerhalb des Containers grundsätzlich keine Rechte haben, auch root nicht. Keine Ahnung, ob das irgendwie relevant ist, wenn wir nun versuchen, mit unseren LDAP-Nutzern auf das durchgereichte Verzeichnis zuzugreifen. Haben die dann die richtigen UIDs? -> ausprobieren.

Eine Alternative wäre, den Container "privileged" zu machen. Das gilt aber als unsicher und wird nicht empfohlen, doch dann würde wohl auch NFS innerhalb des Containers funktionieren und die UIDs sind innen und außen gleich.

Hm, habe mit lxc noch keine Erfahrung …

[Rüdiger Kupper]

Ach so, "veth" steht vermutich für "virtual eth", da geht es also um Netzwerkdevices.

[Rüdiger Kupper]

Okay, hab's geschafft, die Verzeichnisse in den Container durchzureichen, in die 101.conf müssen die Zeilen:

mp0: /home/teachers,mp=/home/teachers
mp1: /home/students,mp=/home/studentss
mp2: /home/share,mp=/home/share

Die uids und guids scheinen mit denen auf dem paedml übereinzustimmen, so dass der Zugriff funktionieren müsste, wenn wir im Container LDAP aufsetzen. Bin gespannt!

[Rüdiger Kupper]

Ähm, nach Neustart des Containers haben nun alle durchgereichten Verzeichnisse die Bestzer nobody/nogroup :-(. Warum nun das auf einmal, eben ging's doch noch??

[Rüdiger Kupper]

Schade, beimersten Versuch hatte ich einen Schreibfehler in der 101.conf …
Das scheint nun das berühmte UID/GUI-Mapping des unpriviligierten Containers zu sein. Wie wir da nun drum herum kommen …

Alternative: LDAP auf dem proxmoxls2 machen und von Nextcloud darauf per sftp zugreifen.

[bau]

• Steht in der Anleitung auf proxmox.com: nobody:nogroup ist so gewollt.
• Wie schon vorgeschlagen: Container privileged machen nach Anleitung, alles andere ist Bastelarbeit.

[Rüdiger Kupper]

Was meinst Du zur Idee, das LDAP auf dem proxmox laufen zu lassen und dorthin sftp zu machen? Das NFS macht er ja nun auch schon?

[Rüdiger Kupper]

In der Proxmox-Doku steht auch etwas zu NFS direkt über den Proxmox:
​https://pve.proxmox.com/pve-docs/pve-admin-guide.html#storage_nfs

Bekommt man damit die NFS-Shares in den Container?

[bau]

Ja, Proxmox kann als Storage natürlich auf Netzwerkfilesysteme zugreifen.
Ich halte aber nichts davon, den Virtualisierer für andere Aufgaben zu benutzen. Das macht vor allem beim Update Probleme: Normalerweise installiere ich den neuen ProxMox auf eine separate SSD und binde dort das Raid und LVM2 auf dem die virtuellen Maschinen liegen wieder ein. Weitere Aufgaben, die der Virtualisierer übernimmt würden das unnötig verkomplizieren.

[Rüdiger Kupper]

Okay.

[Rüdiger Kupper]

Habe den Container unpriviligiert gelassen, aber das Uid/Gid-Mapping angepasst, so dass alle Uids/Gids ab 10000 (das sind die, die die LML für Schüler und Lehrer nutzt)unverändert in den Container übernommen werden.
(Nach der Anleitung hier: ​https://pve.proxmox.com/wiki/Unprivileged_LXC_containers)

Genauer: das Mapping ist jetzt:

Uid 0— 9999(host) —> 100000—109999(container)
Uid 10000–65535(host) —> 10000– 65535(container)

Und ebenso für die Gids.

Jetzt fehlt noch das LDAP.

[Rüdiger Kupper]

LDAP auf dem nextcloud-Server läuft. Du müsstest Dich jetzt per ssh mit bau@cloud einloggen können und wie gewohnt Dein Homeverzeichnis sehen.

[bau]

Bordmittel tun gleich mal nicht mehr:

root@proxmoxls2:~# pct enter 102
lxc-attach: 102: conf.c: lxc_map_ids: 2779 newuidmap failed to write mapping "newuidmap: uid range [0-65536) -> [100000-165536) not allowed": newuidmap 13555 65536 0 1 0 100000 65536
                                                                                                                                                                                      lxc-attach: 102: conf.c: userns_exec_minimal: 4212 Error setting up {g,u}id mappings for child process "13555"

[bau]

Login als User root über die Proxmox-Konsole im Browser geht.

[bau]

Nachdem ich nun eine Route von meinem Laptop zum Cloud-Server gefunden habe (VPN-Tunnel) konnte ich mich problemlos dort einloggen und habe mein HomeVZ gesehen.

[Rüdiger Kupper]

Super! Bei mir dauert der Login immer etwa zehn Sekunden, da ist moch irgendein Timeout am Werk. Ist das bei Dir auch so?

[Rüdiger Kupper]

Replying to bau:

Bordmittel tun gleich mal nicht mehr:

root@proxmoxls2:~# pct enter 102
lxc-attach: 102: conf.c: lxc_map_ids: 2779 newuidmap failed to write mapping "newuidmap: uid range [0-65536) -> [100000-165536) not allowed": newuidmap 13555 65536 0 1 0 100000 65536
                                                                                                                                                                                      lxc-attach: 102: conf.c: userns_exec_minimal: 4212 Error setting up {g,u}id mappings for child process "13555"

Der Nextcloud-Server ist Maschine 101. Der Fehler bei 102 könnte aber trotzdem mit meinen Einträgen zu tun haben, ich schau danach.

[Rüdiger Kupper]

Problem mit den UIDs in Maschine 102 und anderen ist behoben. pct enter funktioniert nun wieder wie gewohnt.
Da bei Maschine 101 einige IDs gar nicht auftreten können hatte ich auch nicht erlaubt, die zu verwenden. Doch die Einstellungen in /etc/subuid und /etc/subgid gelten für alle Maschinen. Hab den erlaubten Bereich nun wieder ausgeweitet, so dass alle Maschinen funktionieren.

[Rüdiger Kupper]

Verbinden der SFTP-Shares von Nextcloud aus klappt derzeit noch nicht, obwohl sftp von der Kommandozeile problemlos klappt. Problem ist noch unklar.

[Rüdiger Kupper]

So, die SFTP-Shares habe ich von Nextcloud aus nicht einbinden können. Meldung war immer "Login failed". Meine Vermutung war, dass beim ersten Verbinden die SSH-Nachfrage kommt wegen des unbekannten Hosts (localhost). Habe deher den Schlüssel von localhost in /etc/sshd/ssh_known_hosts geschrieben. Danach konnte ich mich von der Kommandozeile ohne Nachrage nach localhost verbinden. – Leider klappt der Zugang von Nextcloud aus noch immer nicht. Die Verbindung wird auch nicht vom ssh-Binary gemacht, sondern von einer php-Bibliothek aus. Eventuell schaut die gar nicht nach dem EIntrag in /etc/sshd/ssh_known_hosts und ich hab auch nichts Näheres herausfinden können.

Schließlich habe ich einen "normalen" FTP-Server auf dem cloud-Rechner installiert (​wikipediaDe:vsftpd, ​https://wiki.ubuntuusers.de/vsftpd/). Verschlüsselung brauchen wir ja eh nicht, wenn die Verbindung Rechnerlokal läuft. Nachdem ich den passend konfiguriert hatte und gelernt habe, wie Nextcloud den Pfad zum Homeverzeichnis der Nutzer abfragen kann, klappt der Zugriff nun.

Dein Account ist aktuell zurückgesetzt, Du müsstest Dich einloggen können und die Server-Verzeichnisse sehen. Solange die Verzeichnisse nicht durchgescannt sind (erkennt man daran, dass bei der Größenangabe in NC "Ausstehend" steht), dauert Auflisten und Zugriff noch etwas lang. Beim Testschüler (schuelte) ist der Scan bereits durch, da geht es recht flott.

Was wir im Auge behalten müssen ist die Load auf dem cloud-Rechner. Die geht bei Zugriffen auf den Server gerne mal auf 12 hoch, zuweilen auch darüber. Ob das kritisch ist, weiß ich nicht. Die CPU-Auslastung bleibt dabei immer klein. In den Load-Wert gehen aber neben CPU auch andere Systemgrößen ein, z.B. wartende Netzwerkzugriffe. Ich kann keinen Prozess erkennen, der für den hohen Load-Wert verantwortlich ist. Vielleicht siehst Du da ja etwas.

Jedenfalls ist noch viel Raum für Optimierung. Aber dieses Ticket können wir jetzt erst mal schließen :-).

[Rüdiger Kupper]

Replying to bau:

Damit LXC nfs mounten darf, muss es ein privilegierter Container werden, siehe ​https://theorangeone.net/posts/mount-nfs-inside-lxc/

Klar kann man das NFS auch auf dem Host mounten und durchreichen:
​https://steamforge.net/wiki/index.php/How_to_mount_a_Network_Share_in_a_Linux_Container_under_Proxmox

aber besser wäre es, aus einem unprivileged einen privileged Container zu machen, geht aber nur mit einem Backup/Restore:
​https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

Ja, das behalten wir uns vor, wenn zu viele Schwierigkeiten auftreten. Die unpriviligierten Container sind halt ein Sicherheitsfeature. Bin grade erst dabei, mich mit LXC auseinanderzusetzen.

Was ich jedenfalls schon gemerkt habe: es ist keine gute Idee, mal eben in der .conf "unprivileged=0" einzutragen, um etwas auszuprobieren. Das bringt die ganze Nutzerverwaltung durcheinander. Danach gehört z.B. /var/log dem (echten) Nutzer 0, so dass nach einem Wechsel zurück zu unprivileged=1 keine Ligs mehr geschrieben werden können. Sehr hässlich, hat mich eine Weile gekostet, das wieder hinzubiegen. Also: entweder richtig über backup/restore oder gar nicht wechseln.

[bau]

Das hatte ich beim Lesen der Anleitung gedacht, denn wenn es so einfach wäre, einen provoleged in einen unprivileged und umgekehrt umzuwandeln, warum sollte man dann backup/restore machen?