OK, es sieht so aus, als ob ich heute Abend mal ein Bier trinken werde.
Ich musste zwar erstmal kurz verstehen, wie ich PROXMOX dazu bringe einen Speicherpool mit BTRFS zu erstellen aber hey - hab wieder was gelernt.
Und es lĂ€uft. Leider gerade extreeeeeeeem langsam, weil der Speicherpool auf einer externen USB-Festplatte liegt und ich den kompletten LXC-Container darauf laufen lasse. ABER ⊠ES LĂUFT.
Heute Nachmittag kommt die neue interne Platte. Dann werde ich heute Abend (beim Bier!!!) das ganze nochmal nachstellen. ALS LXC Container mit Debian 13 auf einem BTRFS Dateisystem. Ich bin gespannt.
Aber erstmal ⊠danke danke danke an @scubamuc fĂŒr den anscheinend hilfreichen Tipp.
Und sollte das Laufen sehe ich auch keinen Grund das Ganze in einer VM zu verpacken. Ich persönlich finde die LXC-Container performanter. Aber das wohl Ansichtssache.
âperformanterâ ist sicherlich Ansichtssache, du sparst dir halt etwas Ressourcen weil du ânurâ ein paar Prozesse laufen lĂ€sst anstatt einen ganzes OS mit Kernel.
sehr gerne⊠hab ja nicht umsonst alles dokumentiert SCUBAâs GitHub
hmmm,.. hier wieder vorsicht! ich weiĂ jetzt nicht wie das mit proxmox gemanaged wird, aber wenn du in LXD eine LXC VM erstellst, hat diese eine feste VM-GröĂe (ich glaube 50GB) und ein volume fĂŒr eine VM zu vergröĂern ist nicht ohne, weil das OS in der VM weiĂ ja nichts ĂŒber die volume gröĂenĂ€nderung ⊠so muss die âpartitionâ in der VM vergröĂert werden. da ist ein default LXC viel flexibler und erlaubt flexible volume vergröĂerung.
Naja klingt schon nach ein wenig nach âtweakenâ fĂŒr mich aber jedem das seine. Docker in LXC, BTRFS irgendwie in den LXC gemounted, in dem dann auch Docker lĂ€uft. Klingt alles irgendwie nicht so als wĂ€re es im Sinne des Erfinders oder der Erfinder, aber ja, alles in allem heute wohl ein typisches Homelab Setup. Und ja am Ende gilt: Wenn es funktioniert, warum nicht.
Ich persönlich halte die Dinge lieber simpel und voneinander getrennt, auch aus SicherheitsgrĂŒnden.
Prinzipiell nichts, aber VMs haben halt eine bessere Isolation vom Host und damit auch voneinander. Und Docker in LXC ist nochmal ein komplettes Thema fĂŒr sich, und ich bin da nicht so wirklich tief drinn. Aber sagen wir mal so, sicherer werden die LXCs dadurch nicht.
Btw. kann man mittlerweile Docker eigentlich ohne âTweaksâ in unprivelgierten LXCs nutzen, und funktioniert AIO in so einem LXC?
Yep, ich glaube die Nesting Checkbox ist nun default, also kann man einfach LXC erstellen und mit Docker loslegen.
Wir waren nur leider im problematischen Releasefenster von NC32
Prinzipiell nichts, aber VMs haben halt eine bessere Isolation vom Host und damit auch voneinander. Und Docker in LXC ist nochmal ein komplettes Thema fĂŒr sich, und ich bin da nicht so wirklich tief drinn. Aber sagen wir mal so, sicherer werden die LXCs dadurch nicht.
Kommt immer auf die BedĂŒrfnisse und das Setup an denke ich, aber selbst wenn du es schafft dich auch zwei Containern auszubrechen bist du dann nur ein unprivilegierter User, und ich glaube niemand wird nen Rechteausweitung Exploit an irgendwelchen Nextcloud Boxen verbrennen
Ja wenn es mittlerweile mit Nesting in unpriviligierten Containern funktioniert sieht das natĂŒrlich sicherheitstechnisch schon ganz anders aus, und ist damit denke ich auch ok.
Was ich nicht wirklich abschĂ€tzen kann, ob Docker da nicht doch unter gewissen UmstĂ€nden wieder LĂŒcken aufreissen könnte, k.A. Bei irgendwelchen UID/GID-Ăberlappungen. Wenn man bind-mounts auf Hostpfade nutzt oder irgendwelche Kernel Capabilties an die Docker Container durchgreicht werden. Aber ja wie gesagt, ich kenne mich zuwenig damit aus, um es wirklich abschĂ€tzen zu können.
das ist diskussionswĂŒrdig⊠dir ist schon klar, als âMr. Snapâ wurde bei mir LXD als snap auf Ubuntu installiert und da spielt snap isolation âconfinementâ eine entscheidende rolle. in meinem fall sogar doppelt, weil LXD als snap auf dem host lĂ€uft und die cloud als snap innerhalb des LXCâs. da kommt noch mein docker server im LXC in der LXD snap dazu und lĂ€uft ebenfalls problemlos ohne tweaks mit den vorgeschlagenen defaults die in der snapcraft, snapd und LXD documentation erwĂ€hnt werden⊠also basics, default ohne tweaks.
Naja, die eigentlichen Linux-Container werden ja wohl eher nicht in einem Snap laufen, sondern als normale Systemcontainer auf dem Host. Aber LXD, also der Management-Dienst, lÀuft in einem Snap.
Also nochmals Danke an alle und vor allem an @scubamuc mit dem Tipp zum BTRFS.
Ich habe die Nextcloud jetzt aktiv am Laufen und es funktioniert.
Ein paar Dinge sind mir zwar nicht klar, aber vielleicht hat da ja jemand noch einen Tipp:
Whiteboard - WebSocket-Server
Der Container wird installiert und lĂ€uft aber es werden keine Ports freigegeben. Allerdings benötige ich diese ja, um ihn aktiv zu betreiben. Somit musste ich die Ports manuell aktivieren. Und natĂŒrlich dann noch im Nginx Proxy Server aktivieren (hat mich nochmals ne knappe Stunde gekostet, bis ich daran gedacht habe ). (Meine genutzte Anleitung dafĂŒr)
ClamAV
Sollte der nicht auch einen Port freigegeben haben (3310), denn dies wird in der Konfiguration ja so angegeben. Muss ich den auch manuell öffnen oder lÀuft das beim AIO ohne Freigabe? OK, der Test ergibt es lÀuft .. aber verstehen tu ich es nicht.
Aber nun ⊠ich bin erstmal zufrieden und trinke jetzt ein
PROXMOX Version 9.0.10
LXC mit 4 Kernen, 6 GB RAM, 2 GB SWAP
Vorlage fĂŒr den LXC ist ein Debian 13 Trixie
Systemplatte ist eine Standardplatte LVM mit 20 GB
Datenplatte fĂŒr den Container nextcloud-aio-nextcloud ist eine BTRFS Platte mit 3 TB
Somit ist die Geschwindigkeit durch die Serverplatte gegeben (SSD) und der Datenspeicher erfolgt auf der BTRFS (HDD).
Was heisst es, dass keine Ports freigegeben werden? AIO hat bereits einen Reverse Proxy integriert, der alle Backend-Services ĂŒber Port 443 erreichbar macht. Ich wĂŒsste nicht, dass der Port des Whiteboards in einem vorgeschalteten Reverse Proxy irgendwie explizit erreichbar gemacht werden mĂŒsste. Aber der âWeb Socketsâ-Schalter muss, soweit ich weiss, im NGINX Proxy Manager aktiviert sein.
MĂŒsste auf diesem Port irgendetwas fĂŒr irgendwelche Clients direkt erreichbar sein, irgendein Management-Interface oder so? Falls nein, dann musst du nichts âfreigebenâ und schon gar nicht ins weite, grosse, öffentliche Internet. Und selbst wenn, wĂŒrde ich das nicht ausserhalb des lokalen Netzes erreichbar machen, sondern, wenn nötig, mich nur im LAN direkt via dem entsprechenden Port verbinden.
Nein, den Port fĂŒr den ClamAV wollte ich auch nicht ins Netz veröffentlichen. Mich verwunderte nur, dass er intern mit dem Port 3310 in den Nextcloud Einstellungen angegeben ist und im Portainer sehe ich, dass es keinen Port gibt.
Beim Whiteboard - ja so dachte ich auch. Aber der WebSocket-Server bekam halt keine Verbindung zum Container. Und ich musste halt erstmal suchen und lesen und stellte fest, dass
ich keinen Port habe, der vom Container freigegeben wird und
ich ja auch dem Proxy sagen muss, was er mit der Anfrage anfangen soll und wo sie hingehen soll.
Und wenn ich das alles nicht beachte, dann kommt halt die Fehlermeldung.
Wenn ich nun aber den Container editiere und ihm sage, dass er seine Ports laut Konfiguration selbst erstellen soll (Network ports configuration - Publish all exposed ports to random host ports) dann öffnet er auch einen Port (bei mir 32769:3002). Und mit dieser Information kann ich den Proxy Manager fĂŒttern und dann funktioniert auch der WebSocket-Server.
Eintragung im Proxy Host unter Advanced
location /whiteboard/ {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass http://interne.IP:32769/; # IP der Nextcloud und Port des Containers nextcloud-aio-whiteboard
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Ich verstehe halt nur nicht, warum das nicht automatisch passiert, denn es wird ja alles zusammen installiert.
Beim Antivirus muss höchstwahrscheinlich lediglich eine interne Verbindung von der Nextcloud zum ClamAV-Container bestehen. Beim Whiteboard ist dagegen auch eine Verbindung zu den Clients (Browsern) nötig. Trotzdem bin ich mir nicht sicher, warum es nicht einfach so funktioniert. Meiner Meinung nach muss man in einem Reverse Proxy vor AIO grundsĂ€tzlich nichts an andere Ports als 443 11000 âproxyenâ.
Ich habe aber auch schon das eine oder andere Bier gehabt und momentan keine Ideen mehr. Vielleicht hat ja morgen jemand eine. Vielleicht sogar ich. Ich kann allerdings nicht garantieren, dass es wirklich schon morgen sein wird. AIO lokal hinter einem Reverse Proxy zu testen, steht aber schon lÀnger auf meiner To-do-Liste.
ja, der Port 11000 (oder welchen man halt angibt und nutzt) ist fĂŒr den Reverse Proxy, um den aio-apache zu erreichen. Das ist ja die grundsĂ€tzliche Verbindung.
Aber hier geht es um das Whiteboard bzw. den Server um aktiv gleichzeitig ĂŒberâs Internet synchron zu arbeiten.
Und das ist dann wie Talk, der Port muss extra freigegeben werden. Und zwar im Container an sich und im Reverse Proxy.
Hab AIO jetzt mal aufgesetzt, rein lokal, und alles lĂ€uft out of the Box, ohne irgendwelche extra Ports im Reverse Proxy einzutragen: Browser â Reverse Proxy auf Port 443 â AIO auf Port 11000.
Hier ist was ich getan habe:
Eine Debian 13 VM gestartet und Docker darauf installiert.
In meinem bestenden internen Caddy Reverse Proxy (in einer separten VM), auf dem bereits ein Wildcard Zertifikat fĂŒr *.local.meinedomain.tld installiert ist, folgendes zum Caddyfile hinzugefĂŒgt:
Einen lokalen DNS A Record fĂŒr aio.local.meinedomain.tld in meinem DNS (Unbound auf der pfSense) gesetzt, der auf die IP Adresse der Caddy VM zeigt.
In der Debain VM das docker run Kommando von hier ausgefĂŒhrt, copy & paste ohne etwas anzupassen.
Das Nextcloud AIO Interface unter https://IP.DER.DEBIAN.VM:8080 aufgerufen und als Domainamen aio.local.meinedomain.tld angegeben. Bei der Containerauswahl habe ich alles auf Standard gelassen, sprich Collabora und Whiteboard habe ich installiert, ClamAV nicht.
Gewartet bis alle Container auf grĂŒn waren
Die Nextcloud ĂŒber den Domainnamen aio.local.meinedomain.tld im Browser aufgerufen, mich eingeloggt und gleich mal ein Whiteboard und ein Office File geöffent.
Was soll ich sagen. Das Prozedre hat max. eine halbe Stunde gedauert und alles lÀuft sofort out of the box
Da muss ich gratulieren. Ich finde den AIO ja auch ziemlich gut und der Setup lÀuft auch sehr stabil. Warum er bei mir solche Zicken macht verwundert mich ja auch.
Ich glaube der Unterschied ist hier, warum das mit dem Whiteboard bei dir sofort lĂ€uft, dass es lokal ĂŒber deinen Proxy lĂ€uft.
Bei mir muss er ja ĂŒber die offene Webadresse meines Servers gehen und wenn von dort aus keine Portweiterleitung ĂŒber den Proxy kommt dann entsteht auch keine Verbindung. (also alles mal Vermutung) Der Port selbst ist ins Web ja auch nicht frei, hier findet ja eine Verzeichnis Umleitung auf einen Port statt.
Aber ich hab nachher ein bisschen Zeit, da kann ich nochmal dem Whiteboard Container und dem Proxy spielen, vielleicht geht es auch ohne den offenen Port.
Aber wie ich ja erwÀhnt habe, es ist ja auch eine offizielle Aussage, dass der Port weitergegeben werden muss.
Die Doku, die du verlinkt hast brauchst du bei einer manuellen Installation. Auf meiner produktiven Instanz, die mit Apache, ohne Reverse Proxy davor lĂ€uft, musste ich folgende Zeile zu meinem Apache Virtual Host hinzufĂŒgen:
AIO hat das jedoch bereits vorkonfiguriert und stellt das Whiteboard ebenfalls ĂŒber Port 443 bzw. 11000 in der Reverse-Proxy-Konfiguration bereit. Wichtig bei einem Reverse Proxy davor ist lediglich, dass er Webbocks-Verbindungen korrekt weiterleitet werden. In NPM erreichst du das mit dem entsprechenden Schalter im WebUI, Caddy macht das schon standardmĂ€ssig.
Wenn ich meine AIO Test VM mit nmap -p- scanne, sind nur folgende Ports erreichbar:
22/tcp open ssh
3478/tcp open stun
8080/tcp open http-proxy
11000/tcp open irisa
Wie du siehst, findet er keinen Port 3002, auf dem ja der Whiteboard Container intern erreichbar ist. Wenn ich explizit den Port 3002 scanne, steht da closed:
PORT STATE SERVICE
3002/tcp closed exlm-agent
Trotzdem funktioniert das Whiteboard aber. Warum? Weil die Websocketverbindung nach aussen ĂŒber Port 11000 lĂ€uft und dann intern von AIO auf Port 3002 weitergeleitet wird.
Ok, interessant. Das schaue ich mir mal genauer an.
Den 11000er hab ich ja, sonst wĂŒrde es ja nicht laufen. Aber darĂŒber hĂ€tte er ja keine Verbindung herstellen können.
Naja ich probiere mal, vielleicht geht es auch anders. So wie ich es habe lĂ€uft es halt ĂŒber das Verzeichnis, so war ja auch die ErklĂ€rung in Nextcloud selbst.
Aber danke fĂŒr die Info, ich werde testen und berichten.
So nach lĂ€ngerer Abstinenz nun wieder die RĂŒckmeldung.
Das mit dem Port und dem Container habe ich, ohne die Freigabe im Nginx Proxy Manager, nicht bewerkstelligen können.
Jetzt muss ich auch gestehen, dass ich mittlerweile von Nextcloud AIO doch wieder auf Nextcloud LAMP Stack umgestiegen bin, da ich noch ein paar Probleme hatte, die ich einfach nicht in den Griff bekommen habe.
Zudem finde ich die Konfiguration im LAMP Stack einfacher, aber das ist halt Geschmackssache.
Naja jetzt lĂ€uft alles und auch mein letztes Problem, AppAPI-HaRP, habe ich in den Griff bekommen. Die Anleitung, die hier im Forum verlinkt ist, ist zwar gut aber teilweise ânicht wirklich umsetzbarâ. Ich hatte da so einige Probleme und Fragen und habe erst nach dem Lesen des Github-Eintrags festgestellt wo der Fehler in der Anleitung liegt, jedenfalls was mich betrifft.
Aber ich danke euch allen fĂŒr die Zeit, die MĂŒhe und die Hilfe.
Jetzt kann ich sagen, dass ich blind einen Nextcloud Server aufsetzen kann, egal ob per LAMP-Stack oder per AIO. Hab mir in meinem Wiki alles mitgeschrieben und kann es mittlerweile im Blindflug nachbauen. Und in der Fehlersuche und Fehlerbehebung habe ich echt viel dazu gelernt.
Alles lÀuft jetzt auf einem PROXMOX Server in einem LXC Container und lÀsst sich auch, trotz getrenntem Datenverzeichnis, perfekt per Backup sichern und wiederherstellen.
). (
und momentan keine Ideen mehr. Vielleicht hat ja morgen jemand eine. Vielleicht sogar ich. Ich kann allerdings nicht garantieren, dass es wirklich schon morgen sein wird. AIO lokal hinter einem Reverse Proxy zu testen, steht aber schon lÀnger auf meiner To-do-Liste.
Ich finde den AIO ja auch ziemlich gut und der Setup lÀuft auch sehr stabil. Warum er bei mir solche Zicken macht verwundert mich ja auch.