Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: this_feature_currently_requires_accessing_site_using_safari
Fürn VM-Backup (Linux/Proxmox => Linux/TrueNAS) würde ich eher NFS nutzen (nicht SMB). iSCSI ist ein Blocklevel-Storage und somit eigentlich nicht für den Zugriff mehrerer Clients ausgelegt. Man nutzt das eher für Netzwerk-Boot und nicht für gemeinsame Shares. SMB nimmt man eher für Plattform unabhängige Shares (Linux,Windows,macOS) oder Shares mit komplexer Berechtigungsstruktur (z.B. Domain Controller).Ich habe gesehen das manche ein SMB Share dafür einrichten, andere wieder herum iSCSI nutzen, hat jemand Erfahrung damit, bzw. ist das eine besser als das andere?
Warum nicht mit dem Proxmox Backup Server ?Jedoch möchte ich meine VMs etc. auf dem ZFS Pool, welcher in TrueNAS konfiguriert wurde backuppen.
Um SSL ging es mir gar nicht wirklich, das war nur eine Nebensache, die mir aufgefallen war.
Ich wollte eigentlich eher wissen, ob man für den Betrieb von napp-it auf dem Server (in diesem Fall Proxmox)
Sorry, ich hab mich da vielleicht etwas missverständlich ausgedrückt. Ich gehe von a) aus und beziehe mich deshalb wegen der Security-Anforderungen auf eben genau diese perl-Scripte, welche die API für die napp-it Storage-Verwaltung als root bereit stellen.
- a) einen Apache + von dir entwickelte perl-Scripte installiert oder
- b) napp-it nur als client über standardisierte Protokolle (wie z.B. SSH oder die Proxmox-API) mit dem Server kommuniziert und man das prinzipiell auf jedem PC als reine Client-Anwendung laufen lassen kann, ohne den Server via perl-API zu erweitern
Falls in deinen perl-Scripten also eine Sicherheitslücke aufträte, könnte man diese (ohne die von dir vorgeschlagenen zusätzlichen Firewall-Restriktionen) ausnutzen, um als root Befehle auf dem Server auszuführen... Ich hab mir den Quellcode nicht näher angeschaut - es war nur eine Verständnisfrage, wie napp-it aufgebaut ist.
Sehr schön.Im aktuellen napp-it cs kann man einen https Server nutzen
Das habe ich tatsächlich so gelöst, dass ich von Nginx-Proxy-Manager über meine meinedomain.duckdns.org Adresse ein Letsencrypt-Wildcard-Zertifikat abholen lasse und den lokalen DNS als Standarddomain meinedomain.duckdns.org auflösen lasse.Damit umgeht man das Problem dass web-guis auf Servern im LAN meist kein valides öffentliches Zertifikat haben.
Achtung, bin mir da jetzt auch nicht sicher. Bei meiner Recherche zu NFS und Docker im LXC hab ich was ähnliches gefunden. Der User der den Dienst startet, hat damit afaik keinen Zugriff auf /dev/tty... Entweder User in die Gruppe nogroup, oder dem Port andere User/Gruppen zuweisen. Soweit wäre das jetzt zumindest meine Interpretationnobody nogroup
Weißt du was ich mal interessant finden würde:Proxmox als SMB Server ohne Storage VM
mp0: /rpool/data/shared,mp=/mnt/shared
zvol: /rpool/data/my-zvol,mp=/dev/zvol0
Ja, primär als NAS.Du hast nen TrueNAS Scale (TNS) als Hypervisor baremetal auf nem Ryzen Pro laufen?
Hab ich eh gesagt, ein Debian früher (die VM gibts nicht mehr), jetzt ein Kubuntu (jeweils aktuell), beide mit KDE 5.irgendwas.Debian?
Danke, damit fang ich was an.Im /20er Fall eben 4096 IPs und 4094 Rechner, im /24er sinds 254 Rechner und 256 IPs.
Wie komm ich an den? 🙈Zudem wäre ein Crashlog aus der VM hilfreich. =)
Mai 31 15:32:41 ... kernel: Speculative Return Stack Overflow: IBPB-extending microcode not applied!Zudem wäre ein Crashlog aus der VM hilfreich. =)