[Sammelthread] Proxmox Stammtisch

Du musst die Berechtigungen im Filesystem anpassen. Im Container den Order an den User geben unter dem Paperless läuft.
Gibt's dafür irgendwo nen pfiffiges tutorial? Habe wie der Fragesteller paperless unter docker. Auf dem host ist ein share eines Samba gemountet. Da möchte ich paperless neue Dokumente einsammeln lassen (consume Ordner). Ich bin allerdings frisch in proxmox und docker, weshalb ich nicht verstehe, wie ich das umsetzen kann. Ein tutorial könnte ich aber sicher auf meine Umgebung adaptieren.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe mal eine Frage an die Menge.
Traut ihr bei Updates den Community Repository von Proxmox oder macht bezahlt ihr für das Enterprise Repository?

Gibt es noch eine kostenlose Lösung um ggf. den Server auf halbwegs aktuellen Stand (aber stabil) zu halten? Ich brauch nicht immer das aller neuste im Homelab.
 
ich hatte nur einmal ein Problem, das nach einem Update inkl. Kernelupdate keine USB-Geräte mehr an die VMs durchgereicht wurden, einfach alten Kernel aktiviert und gut war.
Ansonsten bisher seit Jahren keine weiteren Probleme mit Updates aus dem no-subscriptions -Repository.
Ansonsten warte halt immer einige Tage, bzw. ich selbst schaue eh nicht jeden Tag nach, ob es neue Updates gibt.
 
@Senator Wurstbein
Ein Tutorial kenne ich nicht, kann aber ein paar Ausszüge aus meiner Konfig für Immich Posten ;)
Config auf dem Samba Server
Code:
root@pve:~# cat /etc/cockpit/zfs/shares/SSD_share_immich.conf
# COCKPIT ZFS MANAGER
# WARNING: DO NOT EDIT, AUTO-GENERATED CONFIGURATION
[immich]
        path = /SSD/share/immich
        comment = ZFS: SSD/share/immich
        browseable = yes
        read only = no
        guest ok = no

# ADD ADDITIONAL CONFIGURATION HERE
        valid users = <SMB-USER>
        force user = <SMB-USER>
root@pve:~# ls -ld /SSD/share/immich/
drwxrwxr-x 2 immich share 2 Nov  7 18:08 /SSD/share/immich/
root@pve:~# id immich
uid=51003(immich) gid=50000(share) groups=50000(share)

Config auf dem SMB Client
Code:
root@home:~# id immich
uid=1001(immich) gid=1001(immich) groups=1001(immich)
root@home:~# cat /etc/fstab |grep immich
//192.168.40.253/immich                 /immich         cifs    username=<SMB-USer>,password=<SMB-Password>,uid=immich 0 0

Und die Docker Compose Config vom immich bezogen auf den Pfad und User
Code:
name: immich

services:
  immich-server:
    environment:
      - PUID=1001
      - PGID=1001
    volumes:
      - /immich:/usr/src/app/upload

Ich hoffe das hilft
 
Zuletzt bearbeitet:
Ich habe mal eine Frage an die Menge.
Traut ihr bei Updates den Community Repository von Proxmox oder macht bezahlt ihr für das Enterprise Repository?
Das Community Repo ist völlig ausreichend. Das Support Paket bucht man eher, um zeitnahe Lösungen bei Problemen zu erhalten.
Gibt es noch eine kostenlose Lösung um ggf. den Server auf halbwegs aktuellen Stand (aber stabil) zu halten? Ich brauch nicht immer das aller neuste im Homelab.
In dem Fall kannst Du einen beliebigen Stand auch einfach so lange fahren, bis es neue Features gibt, wo Du sagst "das da, das will ich haben".
 
Sodale.
Habe mir ein 8" Full HD Monitörchen geholt (ziemlich nice, leicht, portabel mit Gehäuse, klebt jetzt mit Klettverschluss an meinem kleinen Serverschränkchen und habe so direkt die Möglichkeit zu gucken :d) und habe das Problem direkt gesehen

Anhang anzeigen 1058804

Die NVME wird ejected und read-only wieder eingehangen.

Scheint wohl ein nicht sooooo neues Problem zu sein

Werde dem dann mal auf die Spur gehen.
Smart Werte der NVME sehen gut aus.
So, die Kiste läuft nun stabil.

Es war wohl so, dass Linux die NVME in den Ruhemodus versetzt hat, dann neu gemountet aber read only.

Lösung:
Grub Config anpassen.
/etc/default/grub --> GRUB_CMDLINE_LINUX_DEFAULT="quiet nvme_core.default_ps_max_latency_us=0"
nvme_core.default_ps_max_latency_us=0 hinzugefügt.
 
Gibt's dafür irgendwo nen pfiffiges tutorial? Habe wie der Fragesteller paperless unter docker. Auf dem host ist ein share eines Samba gemountet. Da möchte ich paperless neue Dokumente einsammeln lassen (consume Ordner). Ich bin allerdings frisch in proxmox und docker, weshalb ich nicht verstehe, wie ich das umsetzen kann. Ein tutorial könnte ich aber sicher auf meine Umgebung adaptieren.

Wenn Paperless in einem LXC läuft, kannst du den Ordner vom Server auch als Mountpoint durchleiten. Aber wenn der Share nicht am Proxmox oder eine lokalen LXC gehostet wird, würde ich den Share innerhalb deiner Docker Umgebung mounten.
 
Zum Thema Write Amplification:
1736074267108.png
Haupt-SSD im Proxmox (da liegen die ganzen Service VMs drauf, die 24/7 laufen).
qcow2-files auf ZFS-Dataset...

Frage an die Mannschaft:
Wie bekomme ich die ganzen QCows am einfachsten in ZFS ZVOLs migriert?

//Edith:
Antwort:
1736075469497.png
1736075578684.png

Habs:
Einfach die Disk auf ein leeres Dataset bewegen, dann wird automatisch ein ZVOL erstellt.
Delete Source nicht vergessen. =)
 
Zuletzt bearbeitet:
Hi,

ich habe auf einem Lenovo M910q tiny Proxmox laufen und wollte die WLAN M2 Karte gegen eine 2.5GB Karte tauschen.
Nur leider ist das Netzwerk nach dem Tausch "tot" und ich kann mich nur noch lokal anmelden. Also sagen wir mal die lokale IP ist 192.168.0.10, WLAN wird nicht verwendet.
Nach dem Tausch, auch ohne dass ich ein Kabel in die 2. NIC mit 2.5GB stecke, lässt sich das Gateway unter 192.168.0.1 nicht mehr pingen.

Hier ist die /etc/network/interfaces:

Code:
auto lo
iface lo inet loopback

iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.10/24
        gateway 192.168.0.1
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

iface wlo1 inet manual

Das neue Interface hieß irgendwas wie "enp3s0" und ich habe es manuell reingenommen, wlo1 rausgenommen, hin- und hergetauscht aber nichts hilft.
Bin etwas lost, habe auch keine Lust Proxmox neu zu installieren.

Hat jemand eine Idee?
 
Die PCI Geräte werden fortlaufend durchnummeriert. Steckt man was dazu oder entfernt etwas (WLAN oder auch Nvme SSDs). ändert sich u.a. der generische Name der Netzwerkkarte.

Abhilfe: statische Namen für die Netzwerkkarte vergeben.

Dateien anlegen - für jedes Interface eine eigene Datei

Pfad: /etc/systemd/network

# Datei Parameter
NAME.lnk
zb: 10-en_lan2.link
maske 644
encoding uft-8 ohne BOM

### wichtig: keine Namen mit eth... verwenden, die namen sind reserviert!!
### Name muss mit "en" beginnen!

 
Die PCI Geräte werden fortlaufend durchnummeriert. Steckt man was dazu oder entfernt etwas (WLAN oder auch Nvme SSDs). ändert sich u.a. der generische Name der Netzwerkkarte.

Abhilfe: statische Namen für die Netzwerkkarte vergeben.

Dateien anlegen - für jedes Interface eine eigene Datei

Pfad: /etc/systemd/network

# Datei Parameter
NAME.lnk
zb: 10-en_lan2.link
maske 644
encoding uft-8 ohne BOM

### wichtig: keine Namen mit eth... verwenden, die namen sind reserviert!!
### Name muss mit "en" beginnen!

so hab es mir durchgelesen.
Aber daraus folgt ja, dass das System schon predictable Names bekommt und dort nichts getauscht wurde?
Erklärt für mich dann nicht das Problem dass dann quasi gar kein LAN mehr funktioniert, also das Gateway nicht pingbar ist. die neue Hardware wurde übrigens erkannt mit dem richtigen Chip

edit: hab in einem 2. Server übrigens auch die m2 eingebaut, eingerichtet und es läuft problemlos nach anpassen der /etc/network/interfaces Datei, denke also nicht dass ich ganz grundlegend etwas falsch mache
 
Zuletzt bearbeitet:
Hier nochmal die Checkliste:

Per default bekommen die Netzwerk Interfaces fortlaufend durch nummerierte Namen wie z.B. "enp35s0" , "enp3s0" , whatever...

Wenn man statische Namen haben möchte, sind 2 Änderungen notwendig:

1) Neue Datei "10-en_lan0.link" in /etc/systemd/network erzeugen, passend zur MAC der Netzwerkkarte

<-- Inhalt Text Datei--->

[Match]
MACAddress=77:88:99:13:14:15

[Link]
Name=10-en_lan0

<-------Ende --->

2) in /etc/network/interfaces den alten Interface Namen (enp35s0) durch "en_lan0" - passend zum o.g. Dateinamen ändern.

Und neustart nicht vergessen, oder den Dienst neu starten.
 
Das Community Repo ist völlig ausreichend. Das Support Paket bucht man eher, um zeitnahe Lösungen bei Problemen zu erhalten.

In dem Fall kannst Du einen beliebigen Stand auch einfach so lange fahren, bis es neue Features gibt, wo Du sagst "das da, das will ich haben".
Also du meinst dann nur die Debian und Debian Security Updates installieren und ceph und pve nur bei Bedarf installieren?
 
@Senator Wurstbein
Ein Tutorial kenne ich nicht, kann aber ein paar Ausszüge aus meiner Konfig für Immich Posten ;)
Config auf dem Samba Server
Code:
root@pve:~# cat /etc/cockpit/zfs/shares/SSD_share_immich.conf
# COCKPIT ZFS MANAGER
# WARNING: DO NOT EDIT, AUTO-GENERATED CONFIGURATION
[immich]
        path = /SSD/share/immich
        comment = ZFS: SSD/share/immich
        browseable = yes
        read only = no
        guest ok = no

# ADD ADDITIONAL CONFIGURATION HERE
        valid users = <SMB-USER>
        force user = <SMB-USER>
root@pve:~# ls -ld /SSD/share/immich/
drwxrwxr-x 2 immich share 2 Nov  7 18:08 /SSD/share/immich/
root@pve:~# id immich
uid=51003(immich) gid=50000(share) groups=50000(share)

Config auf dem SMB Client
Code:
root@home:~# id immich
uid=1001(immich) gid=1001(immich) groups=1001(immich)
root@home:~# cat /etc/fstab |grep immich
//192.168.40.253/immich                 /immich         cifs    username=<SMB-USer>,password=<SMB-Password>,uid=immich 0 0

Und die Docker Compose Config vom immich bezogen auf den Pfad und User
Code:
name: immich

services:
  immich-server:
    environment:
      - PUID=1001
      - PGID=1001
    volumes:
      - /immich:/usr/src/app/upload

Ich hoffe das hilft
Das hilft auf jeden Fall schon mal weiter, danke. Grundsätzlich sollte das reichen, um es auf meine Umgebung anzupassen.

Vorab muss ich aber wohl noch ein paar andere Dinge nachlesen - mir war als docker-neuling noch nicht bewusst, dass Container als root laufen. Das scheint normal, aber nicht sicher zu sein, nachdem was ich bisher so gelesen habe. Das sollte ich dann wohl erst korrigieren und dann den neuen User benutzen.

Und zweitens ist mir bei deinem Beispiel nicht ganz klar, warum sich uid/gid auf dem Samba ändern. Weil es id's eines anderen hosts sind? Und wenn ja wie finde ich raus, welche ID auf dem samba gültig ist bzw. welche dort ankommt, wenn ich den docker User nutze?
 
Für den Wechsel der UID/GID ist mein Beispiel auch nicht einfach, weil der User auf beiden Seiten gleich heißt, aber eine andere ID hat ;)

Die Magic passiert im Grunde in der FSTAB mit der username=<SMB-USer> und uid=immich
Hier steht frei interpretiert im Grunde folgendes:
Gebe dich als SMB-User am Samba Server aus um mit der UID SMB-User (UID 51003) auf die Daten zuzugreifen.
Aber hänge das Filesystem mit UID IMMICH (UID 1001) bei mir ein.

Ein kleines bisschen Magie entsteht noch durch das FORCE USER in der smb.conf, da hier unabhängig vom User der auf den Share Zugreift, alle Daten immer mit der UID des angegebenen Users erzeugt werden. Solange nur ein Nutzer verwendet wird ist das egal.
Greifen mehrere Nutzer oder Gruppen zu kann es zu interessanten Problemen kommen, siehe dazu auch das Ubuntu Wiki
 
Also du meinst dann nur die Debian und Debian Security Updates installieren und ceph und pve nur bei Bedarf installieren?
Ich meine das generell. Ein Proxmox hängt i.d.r nicht am Internet und da surft auch keiner drauf rum, der managt nur VMs, und hängt idealerweise im separaten Management vLAN. Wie heisst es so schön: never change a runnig System. Wenn alles läuft wie es soll, *muss* man nicht ständig Updates machen - mehr wie stabil laufen geht nicht. Welche Gefahr von ev. Sicherheitslücken ausgeht, hängt stark vom Einsatzszenario ab. In kleinen oder abgeschotteten Netzen würde ich mal sagen, das man den Punkt vernachlässigen kann. Sind die PVEs zentraler Bestandteil in einer großen Firma oder Rechenzentrum, sieht das anders aus.

Da ist dann die größere Gefahr, das durch Updates bzw neue Features irgendwas inkonsistent wird, so wie letztes Jahr mit den Kernel Updates, die nicht richtig gestestet wurden.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh