## ISO Ubuntu per a la VM PeerTube - Descarreguem la ISO dins del node Proxmox. - Ruta habitual del storage `local`: `/var/lib/vz/template/iso/` - ISO triada: `ubuntu-26.04-live-server-amd64.iso` - Motiu: Ubuntu Server LTS, sense entorn gràfic, adequada per a Docker i serveis de servidor. - La VM PeerTube serà una VM Ubuntu normal, no un LXC, per evitar problemes amb Docker, AppArmor, nesting i muntatges NFS. ## ISO per a la VM PeerTube - Sistema triat: Ubuntu Server 24.04 LTS - Fitxer ISO: ubuntu-24.04-live-server-amd64.iso - Ruta dins Proxmox: /var/lib/vz/template/iso/ - Motiu: Versió LTS madura, estable i molt adequada per a Docker, PeerTube i serveis de servidor. - Objectiu de la VM: Fer de host Docker per a PeerTube, mantenint la base de dades i els volums interns a la VM, i externalitzant la DATA gran de vídeo cap al TrueNAS. # Creació de la VM PeerTube ## 0. Descàrrega prèvia de la ISO Ubuntu Server Abans de crear la màquina virtual, descarreguem la imatge ISO d’Ubuntu Server dins del node Proxmox. La ISO ha d’estar dins del directori d’imatges ISO del storage `local` de Proxmox: ```bash /var/lib/vz/template/iso/ ``` Ens situem dins del directori: ```bash cd /var/lib/vz/template/iso/ ``` Descarreguem Ubuntu Server 24.04 LTS: ```bash wget https://releases.ubuntu.com/24.04/ubuntu-24.04-live-server-amd64.iso ``` Comprovem que la ISO s’ha descarregat correctament: ```bash ls -lh /var/lib/vz/template/iso/ Run this command in your terminal in the directory the iso was downloaded to verify the SHA256 checksum: echo "e907d92eeec9df64163a7e454cbc8d7755e8ddc7ed42f99dbc80c40f1a138433 *ubuntu-24.04.4-live-server-amd64.iso" | shasum -a 256 --check RESULTAT ESPERAT ubuntu-24.04.4-live-server-amd64.iso: OK ``` Hauríem de veure un fitxer semblant a aquest: ```text ubuntu-24.04-live-server-amd64.iso ``` ## Decisió presa Fem servir **Ubuntu Server 24.04 LTS** perquè és una versió estable, de suport llarg i adequada per funcionar com a host Docker. La VM no tindrà entorn gràfic. Només instal·larem el sistema base, SSH, Docker i Docker Compose. ## Objectiu d’aquesta VM Aquesta VM farà de servidor Docker per a PeerTube. A la VM hi deixarem: - el sistema Ubuntu; - Docker i Docker Compose; - els volums interns necessaris; - la base de dades PostgreSQL; - Redis; - configuració pròpia de PeerTube. Al TrueNAS hi deixarem: - els vídeos; - els fitxers originals; - les llistes HLS / streaming; - les miniatures i previews pesades; - les carpetes d’importació; - les dades grans que puguin créixer molt. ## Esquema general ```text Internet | v CT Apache Reverse Proxy | | HTTP intern cap a PeerTube v VM Ubuntu Server 24.04 + Docker | | NFS v TrueNAS 192.168.100.101 ``` # Creació de la VM PeerTube ## 1. Creació de la màquina virtual a Proxmox Crearem una nova màquina virtual Ubuntu Server 24.04 LTS que farà de host Docker per al servei PeerTube. L’objectiu és evitar els problemes propis d’executar Docker dins d’un contenidor LXC privilegiat i disposar d’un sistema Linux complet, més proper a un servidor real. La VM PeerTube tindrà: - Ubuntu Server 24.04 LTS. - Docker i Docker Compose. - PeerTube desplegat amb Docker Compose. - Base de dades PostgreSQL en volum local de la VM. - Redis en volum local de la VM. - Volums interns petits en disc local. - Dades grans de vídeo muntades des del TrueNAS per NFS. El TrueNAS es troba a: ```text 192.168.100.101 ``` ## 2. Inici de l’assistent de creació Des de la interfície web de Proxmox: ```text Datacenter → Node base → Create VM ``` En aquest cas el node Proxmox és: ```text base ``` ## 3. Pestanya General En aquesta pestanya definim el nom i l’identificador de la VM. ### Valors recomanats ```text Node: base VM ID: el següent disponible Name: peertube-vm Resource Pool: buit, si no en fem servir cap Start at boot: activat, si volem que arrenqui automàticament amb el Proxmox ``` El nom pot ser, per exemple: ```text peertube-vm ``` També podríem fer servir un nom més descriptiu: ```text vm-peertube-docker ``` ## 4. Decisió presa Creem una VM dedicada exclusivament a PeerTube i Docker. Aquesta VM no farà de proxy invers públic. Aquesta funció continuarà separada en un altre CT amb Apache. La separació quedarà així: ```text CT Apache Reverse Proxy → publica el servei web → gestiona HTTPS → fa proxy cap a la VM PeerTube VM PeerTube → executa Docker → executa PeerTube → executa PostgreSQL → executa Redis → munta les dades grans des del TrueNAS VM TrueNAS → emmagatzema la DATA gran de vídeo → exporta datasets per NFS ``` ## 5. Justificació Aquesta arquitectura separa clarament les funcions: - El proxy invers queda aïllat del servei d’aplicació. - Docker funciona dins d’una VM completa, no dins d’un LXC. - Les dades grans no ocupen el disc intern de la VM PeerTube. - PostgreSQL queda local a la VM per evitar problemes de rendiment i consistència sobre NFS. - TrueNAS fa el paper que li correspon: emmagatzematge persistent i compartit. ## 6. Resum de la pestanya General ```text Node: base VM ID: següent lliure Name: peertube-vm Start at boot: sí ``` ## 7. Nota sobre el VM ID El VM ID pot ser qualsevol identificador lliure dins de Proxmox. Per exemple: ```text 1110 ``` o un de nou, si el 1110 ja està ocupat. Si volem comprovar des de terminal les màquines existents: ```bash root@base:~# qm list ``` Això mostrarà les VMs existents i ens ajudarà a no repetir cap VM ID. Exemple de sortida esperada: ```text VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID 100 truenas running 8192 80.00 ... 1110 peertube-old stopped 8192 80.00 ... ``` En cas que el VM ID proposat ja existeixi, triem el següent lliure. ## 8. Estat del procés Un cop omplerta la pestanya General, passem a la pestanya següent: ```text OS ``` # Creació de la VM PeerTube ## 2. Pestanya OS En aquesta pestanya indiquem quina ISO farà servir la màquina virtual per arrencar la instal·lació del sistema operatiu. La ISO ja l’hem descarregada prèviament dins del node Proxmox, a la ruta habitual del storage `local`: ```bash root@base:/var/lib/vz/template/iso# ls -lh ``` Hauríem de veure el fitxer: ```text ubuntu-24.04-live-server-amd64.iso ``` ## Valors recomanats a la pestanya OS A l’assistent de Proxmox seleccionem: ```text Use CD/DVD disc image file (iso): activat Storage: local ISO image: ubuntu-24.04-live-server-amd64.iso Guest OS Type: Linux Version: 6.x - 2.6 Kernel ``` ## Decisió presa Fem servir **Ubuntu Server 24.04 LTS** com a sistema operatiu de la VM PeerTube. No instal·larem entorn gràfic, perquè aquesta màquina només farà de servidor. La VM tindrà únicament: - sistema base Ubuntu Server; - accés SSH; - Docker; - Docker Compose; - muntatge NFS contra TrueNAS; - desplegament de PeerTube. ## Justificació Ubuntu Server 24.04 LTS és una versió estable i amb suport llarg. És adequada per a aquest projecte perquè: - té bon suport per Docker; - és una distribució molt documentada; - evita els problemes específics de Docker dins LXC; - permet muntar NFS de manera normal; - és més previsible que un contenidor privilegiat. ## Resum de la pestanya OS ```text ISO: ubuntu-24.04-live-server-amd64.iso Storage ISO: local Guest OS: Linux Version: 6.x - 2.6 Kernel ``` ## Estat del procés Un cop seleccionada la ISO d’Ubuntu Server 24.04 LTS, passem a la pestanya següent: ```text System ``` # Creació de la VM PeerTube ## 3. Pestanya System En aquesta pestanya configurem alguns paràmetres interns de la màquina virtual: BIOS, firmware, controlador SCSI, TPM i opcions bàsiques de maquinari virtual. Per a una VM Ubuntu Server a Proxmox, pensada per funcionar com a servidor Docker, podem fer una configuració senzilla i estable. ## Valors recomanats a la pestanya System ```text Graphic card: Default Machine: q35 BIOS: OVMF (UEFI) Add EFI Disk: activat EFI Storage: local-lvm o el storage on posarem els discos de la VM Pre-Enroll keys: desactivat SCSI Controller: VirtIO SCSI single Qemu Agent: activat Add TPM: desactivat ``` ## Sobre el mode UEFI Fem servir: ```text BIOS: OVMF (UEFI) ``` Això crea una VM moderna amb arrencada UEFI. També cal marcar: ```text Add EFI Disk ``` El disc EFI és petit i només guarda dades d’arrencada UEFI de la màquina virtual. ## Sobre les claus Secure Boot Deixem aquesta opció desactivada: ```text Pre-Enroll keys: no ``` No necessitem Secure Boot per a aquesta VM. Volem una instal·lació simple, fàcil de mantenir i sense complicacions extra. ## Sobre el controlador SCSI Triem: ```text SCSI Controller: VirtIO SCSI single ``` Aquest controlador és eficient i habitual en VMs Linux dins Proxmox. És una bona opció per rendiment i compatibilitat amb Ubuntu Server. ## Sobre Qemu Agent Activem: ```text Qemu Agent: yes ``` Això permet que Proxmox es comuniqui millor amb la VM. Serveix per veure informació interna de la màquina i fer operacions més netes, com apagats controlats. Després, dins d’Ubuntu, instal·larem el paquet corresponent: ```bash root@peertube-vm:~# apt install qemu-guest-agent ``` I l’activarem: ```bash root@peertube-vm:~# systemctl enable --now qemu-guest-agent ``` ## Sobre TPM Deixem TPM desactivat: ```text Add TPM: no ``` No és necessari per a una VM Ubuntu Server destinada a Docker i PeerTube. ## Decisió presa Configurem la VM amb UEFI, controlador VirtIO SCSI i Qemu Agent activat. Això dona una màquina virtual moderna, eficient i còmoda de gestionar des de Proxmox. ## Justificació Aquesta configuració és adequada perquè: - Ubuntu Server 24.04 funciona bé amb UEFI. - VirtIO SCSI ofereix bon rendiment. - Qemu Agent facilita la gestió des de Proxmox. - No necessitem TPM ni Secure Boot. - Reduïm complexitat innecessària. ## Resum de la pestanya System ```text Graphic card: Default Machine: q35 BIOS: OVMF (UEFI) EFI Disk: sí FORMAT: QEMU qcow2 Pre-Enroll keys: no SCSI Controller: VirtIO SCSI single Qemu Agent: sí TPM: no ``` ## Estat del procés Un cop configurada la pestanya System, passem a la pestanya següent: ```text Disks ``` # Creació de la VM PeerTube ## 4. Pestanya Disks En aquesta pestanya configurem el disc principal de la VM Ubuntu Server. Aquesta VM farà de host Docker per a PeerTube, però no volem que el disc intern guardi tota la DATA gran de vídeo. Els vídeos i fitxers pesats aniran al TrueNAS. Per tant, el disc de la VM ha de ser suficient per al sistema, Docker, PostgreSQL, Redis, logs i configuració, però no cal dimensionar-lo com si hagués d’emmagatzemar tota la mediateca. ## Valors recomanats a la pestanya Disks ```text Bus/Device: SCSI Storage: local-lvm o el storage ràpid disponible per a VMs Disk size: 80 GB o 100 GB Cache: Default / No cache Discard: activat IO thread: activat SSD emulation: activat si el storage físic és SSD Backup: activat Format: qcow2 si el storage és directory; raw/LVM-thin si és local-lvm ``` ## Mida del disc Proposta recomanada: ```text Disk size: 100 GB ``` També seria acceptable: ```text Disk size: 80 GB ``` ## Decisió presa Assignem un disc d’aproximadament: ```text 100 GB ``` Aquest disc contindrà: - Ubuntu Server 24.04 LTS; - Docker; - Docker Compose; - imatges Docker; - volums interns de Docker; - base de dades PostgreSQL; - Redis; - configuració de PeerTube; - logs del sistema i dels contenidors. No contindrà la DATA gran de vídeo. ## Què NO volem guardar principalment en aquest disc No volem que aquest disc sigui el magatzem principal de: - vídeos originals; - vídeos transcodificats; - HLS / streaming playlists; - miniatures grans; - previews; - imports massius; - còpies grans de contingut audiovisual. Aquestes dades han d’anar al TrueNAS: ```text TrueNAS 192.168.100.101 ``` ## Bus del disc Triem: ```text Bus/Device: SCSI ``` Això encaixa amb la decisió de la pestanya anterior: ```text SCSI Controller: VirtIO SCSI single ``` ## Storage del disc Si el Proxmox té `local-lvm`, és una opció habitual per a discos de VM: ```text Storage: local-lvm ``` Si tens un altre storage més ràpid o més adequat per a VMs, també seria correcte. La idea és que el disc intern de la VM sigui raonablement ràpid, especialment per PostgreSQL. ## Format del disc Segons el tipus de storage: ```text Si el storage és directory: qcow2 Si el storage és local-lvm: raw / LVM-thin ``` Si Proxmox ofereix explícitament aquestes opcions: ```text RAW disk image QEMU image / qcow2 VMware image / vmdk ``` La tria recomanada és: ```text QEMU image / qcow2 ``` però si estem sobre `local-lvm`, és normal que Proxmox treballi amb volum LVM-thin i format tipus `raw`. ## Cache Deixem: ```text Cache: Default / No cache ``` Per a una VM servidor amb base de dades PostgreSQL és millor no fer invents amb cache agressiva. Evitem opcions com `Write back` si no tenim clar el risc, perquè en cas de tall elèctric o caiguda del host podríem tenir més risc de corrupció de dades. ## Discard Activem: ```text Discard: yes ``` Això permet que la VM informi el storage quan allibera blocs de disc. És útil especialment amb storages thin provisioned, SSD o LVM-thin. ## IO thread Activem: ```text IO thread: yes ``` Això pot millorar el comportament d’entrada/sortida del disc virtual, sobretot en VMs amb càrrega de servei. ## SSD emulation Activem: ```text SSD emulation: yes ``` si el disc físic o storage real és SSD. Si el storage real és disc mecànic, no cal activar-ho. ## Backup Deixem: ```text Backup: yes ``` Tot i que la DATA gran estarà al TrueNAS, aquesta VM conté parts importants: - PostgreSQL; - configuració; - volums de Docker; - fitxers de desplegament. Per tant, convé que entri dins de les còpies de seguretat de Proxmox. ## Resum de la pestanya Disks ```text Bus/Device: SCSI Storage: local-lvm Disk size: 100 GB Cache: Default / No cache Discard: yes IO thread: yes SSD emulation: yes, si el storage real és SSD Backup: yes Format: qcow2 si és storage directory; raw/LVM-thin si és local-lvm ``` ## Justificació El disc intern de la VM es reserva per al sistema i les dades que convé mantenir locals, especialment PostgreSQL. La base de dades no es posa al TrueNAS per NFS perquè una base de dades sobre NFS pot donar problemes de rendiment, bloquejos i consistència. La DATA gran de vídeo sí que es posarà al TrueNAS, perquè és el tipus de dada que encaixa millor amb un NAS. ## Esquema de decisió ```text Disc VM PeerTube ├── Ubuntu Server ├── Docker ├── PostgreSQL ├── Redis ├── configuració └── logs TrueNAS ├── vídeos originals ├── vídeos transcodificats ├── HLS / streaming playlists ├── thumbnails ├── previews └── imports ``` ## Estat del procés Un cop configurada la pestanya Disks, passem a la pestanya següent: ```text CPU ``` # Creació de la VM PeerTube ## 4. Correcció de la pestanya Disks A la pestanya **Disks** faltava documentar una opció important relacionada amb l’entrada/sortida del disc: ```text Async IO ``` ## Opció recomanada Per a aquesta VM deixem: ```text Async IO: Default (io_uring) ``` ## Què és `io_uring` `io_uring` és el mecanisme modern del kernel Linux per gestionar operacions d’entrada/sortida asíncrones. En una VM Proxmox, això afecta com QEMU/KVM gestiona les lectures i escriptures del disc virtual. ## Decisió presa Deixem l’opció per defecte: ```text Default (io_uring) ``` ## Justificació És una bona opció per a aquesta VM perquè: - és el valor modern recomanat per defecte en Proxmox; - ofereix bon rendiment en càrregues de disc; - encaixa bé amb VMs Linux modernes; - Ubuntu Server 24.04 funciona bé en aquest escenari; - no cal forçar opcions més antigues si no tenim cap error concret. ## Alternatives Proxmox pot oferir altres opcions com: ```text native threads io_uring ``` En aquest cas no cal canviar-ho manualment. Només tindria sentit provar una alternativa si apareguessin errors concrets d’I/O, bloquejos estranys o problemes de compatibilitat amb el storage. ## Resum actualitzat de la pestanya Disks ```text Bus/Device: SCSI Storage: local-lvm Disk size: 100 GB Cache: Default / No cache Discard: yes IO thread: yes SSD emulation: yes, si el storage real és SSD Backup: yes Async IO: Default (io_uring) Format: qcow2 si és storage directory; raw/LVM-thin si és local-lvm ``` ## Decisió final de la pestanya Disks El disc intern de la VM PeerTube queda pensat per al sistema i les dades que convé mantenir locals: - Ubuntu Server; - Docker; - imatges Docker; - volums interns; - PostgreSQL; - Redis; - configuració; - logs. La DATA gran de vídeo anirà al TrueNAS i no al disc intern de la VM. ```text Disc local VM PeerTube ├── sistema Ubuntu ├── Docker ├── PostgreSQL ├── Redis └── configuració TrueNAS 192.168.100.101 ├── vídeos originals ├── vídeos transcodificats ├── HLS / streaming playlists ├── thumbnails ├── previews └── imports ``` # Creació de la VM PeerTube ## 5. Pestanya CPU En aquesta pestanya configurem els recursos de processador assignats a la VM Ubuntu Server que farà de host Docker per a PeerTube. PeerTube pot fer servir CPU de manera intensiva, sobretot quan ha de transcodificar vídeos. Per això convé donar-li una quantitat de CPU suficient, però sense deixar el node Proxmox sense marge. ## Valors recomanats a la pestanya CPU ```text Sockets: 1 Cores: 4 Type: host Enable NUMA: no Extra CPU Flags: buit ``` ## Decisió presa Assignem a la VM: ```text 1 socket 4 cores CPU type: host ``` ## Justificació Fem servir: ```text Type: host ``` perquè la VM pugui aprofitar millor les característiques reals del processador físic del servidor Proxmox. Això és recomanable per a una VM que executarà Docker i serveis que poden fer ús intensiu de CPU, especialment en tasques de vídeo. ## Sobre el nombre de cores Una proposta equilibrada és: ```text Cores: 4 ``` Això hauria de ser suficient per: - executar PeerTube; - executar PostgreSQL; - executar Redis; - executar tasques de backend; - fer transcodificacions moderades; - mantenir marge per al sistema. Si més endavant veiem que la transcodificació va massa lenta, es pot ampliar. ## Sobre sockets Fem servir: ```text Sockets: 1 ``` No cal simular diversos sockets. Per a aquesta VM és millor una configuració senzilla: ```text 1 socket x 4 cores ``` ## Sobre NUMA Deixem: ```text Enable NUMA: no ``` NUMA només tindria sentit en màquines molt grans, amb molts cores i molta memòria. Per a aquesta VM no cal. ## Sobre CPU limits No posem cap límit artificial de CPU en aquest moment. La VM podrà fer servir els cores assignats quan els necessiti, però Proxmox continuarà gestionant el repartiment de recursos amb la resta de màquines. ## Resum de la pestanya CPU ```text Sockets: 1 Cores: 4 Type: host NUMA: no Extra CPU Flags: buit ``` ## Nota sobre transcodificació La transcodificació de vídeo és una de les parts més costoses de PeerTube. Amb 4 cores podem començar de manera raonable, però caldrà observar el comportament real del sistema. Si es fan moltes pujades de vídeo o moltes resolucions de sortida, pot ser necessari: - augmentar cores; - limitar la concurrència de transcodificació; - fer servir resolucions més modestes; - externalitzar o programar les tasques pesades; - revisar si interessa acceleració per hardware, si el host ho permet. ## Decisió final de CPU La VM PeerTube queda configurada inicialment amb: ```text 1 socket x 4 cores CPU type host ``` És una configuració prudent per començar: suficient per una prova funcional i ampliable si el servei creix. ## Estat del procés Un cop configurada la pestanya CPU, passem a la pestanya següent: ```text Memory ``` # Creació de la VM PeerTube ## 5. Correcció de la pestanya CPU A la pestanya **CPU** faltava documentar el camp: ```text CPU units ``` Aquest camp serveix per donar més o menys prioritat relativa a una VM quan diverses màquines competeixen per CPU dins del mateix node Proxmox. ## Opció recomanada Per a aquesta VM deixem: ```text CPU units: 1024 ``` Aquest és el valor per defecte habitual. ## Què vol dir CPU units `CPU units` no assigna més cores reals a la VM. La quantitat de cores la defineix aquest altre apartat: ```text Sockets: 1 Cores: 4 ``` En canvi, `CPU units` defineix la prioritat relativa quan hi ha contenció de CPU. És a dir: quan el node Proxmox va sobrat de CPU, aquest valor pràcticament no es nota. Quan el node està carregat, Proxmox el fa servir per decidir quin pes té cada VM en el repartiment de CPU. ## Decisió presa Deixem: ```text CPU units: 1024 ``` ## Justificació No cal tocar aquest valor ara perquè: - és una VM important, però encara estem en fase de desplegament; - no volem donar-li una prioritat exagerada respecte a altres serveis; - PeerTube pot consumir CPU durant la transcodificació, però això ho controlarem millor des de la configuració de PeerTube; - mantenir el valor per defecte facilita entendre el comportament inicial del sistema. ## Quan tindria sentit canviar CPU units Podríem pujar aquest valor si més endavant veiem que la VM PeerTube queda massa penalitzada quan el node Proxmox està carregat. Per exemple: ```text CPU units: 2048 ``` Això li donaria més pes respecte a altres VMs amb `1024`. També podríem baixar-lo si volem que PeerTube no molesti altres serveis quan estigui transcodificant. Per exemple: ```text CPU units: 512 ``` Això faria que, en situació de càrrega, PeerTube tingués menys prioritat. ## Important No confondre: ```text Cores ``` amb: ```text CPU units ``` Els cores indiquen quants vCPU pot veure i utilitzar la VM. Les CPU units indiquen la prioritat relativa d’aquesta VM quan competeix amb altres VMs. ## Resum actualitzat de la pestanya CPU ```text Sockets: 1 Cores: 4 Type: host CPU units: 1024 Enable NUMA: no Extra CPU Flags: buit ``` ## Decisió final de CPU Configurem la VM PeerTube amb: ```text 1 socket 4 cores CPU type: host CPU units: 1024 NUMA: no ``` És una configuració equilibrada per començar. PeerTube podrà fer tasques de transcodificació, però sense donar-li una prioritat especial per sobre de la resta de serveis del node Proxmox. # Creació de la VM PeerTube ## 6. Pestanya Memory En aquesta pestanya configurem la memòria RAM assignada a la VM Ubuntu Server que farà de host Docker per a PeerTube. PeerTube no és només un servei web senzill. També executarà diversos serveis interns, especialment: - PeerTube; - PostgreSQL; - Redis; - workers; - processos de transcodificació; - tasques de manteniment; - accés a dades muntades des del TrueNAS. Per això convé no deixar-la massa curta de memòria. ## Valors recomanats a la pestanya Memory ```text Memory: 8192 MiB Minimum memory: buit / no ballooning Ballooning Device: desactivat Shares: per defecte ``` ## Decisió presa Assignem a la VM: ```text Memory: 8192 MiB ``` És a dir: ```text 8 GB de RAM ``` ## Justificació 8 GB és una quantitat raonable per començar perquè permet executar amb marge: - sistema Ubuntu Server; - Docker; - PeerTube; - PostgreSQL; - Redis; - processos auxiliars; - alguna transcodificació moderada. No és una configuració enorme, però és suficient per a una prova funcional i per a un desplegament petit o mitjà. ## Sobre Ballooning Deixem el ballooning desactivat: ```text Ballooning Device: no ``` o, si la interfície mostra un camp de memòria mínima: ```text Minimum memory: buit ``` ## Què és el Ballooning El ballooning permet que Proxmox retiri o retorni RAM a una VM segons la pressió de memòria del host. Això pot ser útil en entorns amb moltes VMs, però per a aquesta VM preferim una assignació estable. ## Per què no fem servir Ballooning aquí No activem ballooning perquè aquesta VM tindrà serveis sensibles a memòria i rendiment: - PostgreSQL; - PeerTube; - Docker; - processos de vídeo. És millor que la VM tingui una quantitat de RAM fixa i previsible. ## Sobre PostgreSQL PostgreSQL es quedarà dins de la VM, en volum local. Això fa que sigui encara més recomanable tenir memòria estable, perquè la base de dades aprofita la RAM per cache i funcionament intern. ## Sobre la DATA de vídeo Tot i que la DATA gran de vídeo anirà al TrueNAS, la VM continuarà necessitant RAM per gestionar: - peticions web; - indexació; - metadades; - cues de treball; - transcodificació; - accés als fitxers muntats per NFS. Per tant, el fet que els vídeos vagin al NAS no vol dir que la VM pugui anar molt curta de RAM. ## Opcions possibles Configuració mínima acceptable: ```text Memory: 4096 MiB ``` Aquesta opció pot servir per a proves molt petites, però pot quedar justa. Configuració recomanada: ```text Memory: 8192 MiB ``` Configuració més còmoda si hi ha recursos disponibles: ```text Memory: 12288 MiB ``` o bé: ```text Memory: 16384 MiB ``` ## Decisió final de memòria Per començar triem: ```text Memory: 8192 MiB Ballooning: desactivat ``` Aquesta configuració és equilibrada: dona marge suficient a PeerTube sense consumir de manera exagerada els recursos del node Proxmox. ## Resum de la pestanya Memory ```text Memory: 8192 MiB Minimum memory: buit Ballooning Device: no Shares: per defecte ``` ## Estat del procés Un cop configurada la pestanya Memory, passem a la pestanya següent: ```text Network ``` # Creació de la VM PeerTube ## 7. Pestanya Network En aquesta pestanya configurem la targeta de xarxa virtual de la VM Ubuntu Server. Aquesta VM ha de poder comunicar-se amb: - el TrueNAS, situat a `192.168.100.101`; - el CT Apache que farà de proxy invers; - internet, per descarregar paquets, imatges Docker i actualitzacions; - la resta de serveis interns del laboratori. ## Valors recomanats a la pestanya Network ```text Bridge: vmbr0 Model: VirtIO (paravirtualized) MAC address: auto VLAN Tag: buit, si no estem separant per VLAN Firewall: activat o desactivat segons política del Proxmox Disconnect: no MTU: buit / default Queues: buit / default ``` ## Decisió presa Fem servir: ```text Bridge: vmbr0 Model: VirtIO (paravirtualized) ``` ## Justificació Triem `vmbr0` perquè és el bridge principal del node Proxmox i permet que la VM es comporti com una màquina més de la xarxa. Això farà que la VM PeerTube pugui tenir una IP pròpia dins la xarxa del laboratori. Per exemple: ```text TrueNAS: 192.168.100.101 PeerTube VM: 192.168.100.xxx Apache Proxy: 192.168.100.xxx o la xarxa interna corresponent ``` La IP exacta de la VM PeerTube la configurarem després durant la instal·lació d’Ubuntu o posteriorment amb `netplan`. ## Model de targeta Triem: ```text Model: VirtIO (paravirtualized) ``` VirtIO és el model recomanat per a Linux dins Proxmox perquè ofereix millor rendiment que targetes emulades com Intel E1000. ## VLAN Tag Deixem: ```text VLAN Tag: buit ``` Això vol dir que la VM entrarà directament a la xarxa associada al bridge `vmbr0`. Només posaríem una VLAN si el Proxmox ja tingués una configuració de xarxa amb VLANs i volguéssim situar aquesta VM dins una VLAN concreta. ## Firewall Hi ha dues opcions raonables: ```text Firewall: no ``` o bé: ```text Firewall: yes ``` Per començar, si encara no tenim regles definides a Proxmox, podem deixar-lo desactivat. La seguretat principal la controlarem amb: - el firewall del propi Ubuntu, si cal; - el reverse proxy Apache; - el fet que PeerTube no s’exposarà directament a internet; - la separació entre proxy i aplicació. ## Decisió recomanada per començar ```text Firewall: no ``` Més endavant, quan tinguem clar quins ports necessitem, podem activar firewall i afegir regles. ## Ports que previsiblement necessitarà la VM PeerTube La VM PeerTube haurà d’escoltar internament el servei web de PeerTube, normalment: ```text 9000/tcp ``` Aquest port no cal exposar-lo públicament. Només l’haurà de poder veure el CT Apache Reverse Proxy. També necessitarà sortida cap a internet per: ```text 80/tcp 443/tcp 53/udp 123/udp ``` I accés cap al TrueNAS per NFS: ```text 2049/tcp ``` Segons la versió/configuració de NFS, també poden intervenir altres ports, però si fem NFSv4 normalment el port principal és el `2049`. ## Esquema de xarxa previst ```text Internet | v CT Apache Reverse Proxy | | HTTP intern cap a port 9000 v VM Ubuntu Server PeerTube | | NFS cap a 192.168.100.101 v TrueNAS ``` ## Configuració d’IP En aquesta pestanya de Proxmox no configurem encara la IP del sistema operatiu. La IP es configurarà després dins d’Ubuntu Server. Podem fer-ho de dues maneres: ```text Opció A: DHCP inicial i després reserva al router Opció B: IP estàtica amb netplan dins d’Ubuntu ``` Per a un servidor, la millor opció final és IP estàtica. Per exemple: ```text PeerTube VM: 192.168.100.102 TrueNAS: 192.168.100.101 Gateway: 192.168.100.1 DNS: 1.1.1.1 / 8.8.8.8 / DNS local ``` La IP exacta la podem decidir quan instal·lem Ubuntu. ## Resum de la pestanya Network ```text Bridge: vmbr0 Model: VirtIO (paravirtualized) MAC address: auto VLAN Tag: buit Firewall: no, inicialment Disconnect: no MTU: default Queues: default ``` ## Decisió final de xarxa La VM PeerTube queda connectada al bridge principal de Proxmox amb una targeta VirtIO. Això permetrà que la màquina tingui connectivitat directa amb el TrueNAS i amb el CT Apache que farà de proxy invers. La VM no publicarà directament el servei cap a internet. El servei públic continuarà passant pel CT Apache. ## Estat del procés Un cop configurada la pestanya Network, passem a la pestanya següent: ```text Confirm ``` # Instal·lació d’Ubuntu Server 24.04 a la VM PeerTube ## 8. Instal·lador Ubuntu Server: idioma, teclat i tipus d’instal·lació Un cop creada la VM a Proxmox i arrencada amb la ISO d’Ubuntu Server 24.04 LTS, comença l’assistent d’instal·lació del sistema operatiu. En aquesta fase configurem: - idioma de l’instal·lador; - distribució del teclat; - tipus d’instal·lació; - drivers de tercers. ## Idioma de l’instal·lador Seleccionem: ```text Català ``` Això farà que l’instal·lador mostri els menús en català. ## Teclat A l’apartat de teclat, fem servir la detecció automàtica per pulsacions. Opció triada: ```text Detectar la disposició del teclat ``` Durant la detecció, l’instal·lador demana prémer algunes tecles. Això permet identificar correctament el tipus de teclat. El resultat esperat seria un teclat de tipus: ```text Spanish / Catalan-compatible ``` o equivalent, segons com ho mostri l’instal·lador. ## Decisió presa sobre el teclat Fem servir la detecció automàtica perquè és la manera més segura d’evitar errors amb caràcters importants com: ```text / - _ : ; @ ``` Això és important perquè aquesta VM es gestionarà molt per terminal i SSH. ## Tipus d’instal·lació L’instal·lador ofereix opcions semblants a: ```text Ubuntu Server Ubuntu Server (minimal) ``` Per aquesta VM triem: ```text Ubuntu Server ``` ## Per què no triem Minimal Server La instal·lació mínima pot semblar atractiva perquè instal·la menys paquets, però per a aquest cas no ens aporta gaire avantatge. Aquesta VM farà de host Docker per a PeerTube i necessitarem una base de sistema còmoda, amb eines habituals de servidor. Amb la instal·lació normal d’Ubuntu Server tindrem una base més pràctica per administrar el sistema. ## Decisió presa Seleccionem: ```text Ubuntu Server ``` No seleccionem: ```text Ubuntu Server (minimal) ``` ## Justificació Triem la instal·lació normal perquè aquesta VM haurà de fer tasques de servidor reals: - instal·lar Docker; - instal·lar Docker Compose; - muntar NFS; - gestionar serveis amb systemd; - administrar xarxa; - revisar logs; - instal·lar eines bàsiques de diagnosi; - mantenir PeerTube i els seus contenidors. La versió minimal és més austera, però després probablement hauríem d’instal·lar manualment més eines bàsiques. ## Drivers de terceres parts Marquem l’opció: ```text Install third-party drivers ``` o equivalent en català: ```text Instal·lar controladors de tercers ``` ## Decisió presa sobre drivers Activem els drivers de tercers. ## Justificació Tot i que és una VM i normalment no necessitarem drivers especials de Wi-Fi, GPU o maquinari físic, marcar aquesta opció no és problemàtic en aquest escenari. Pot ajudar si Ubuntu detecta algun component virtual o suport addicional que sigui convenient instal·lar. En una VM de servidor no és una opció crítica, però la deixem activada perquè no ens perjudica i pot evitar mancances puntuals. ## Resum d’aquesta pantalla ```text Idioma: Català Teclat: detectat per pulsacions Tipus d’instal·lació: Ubuntu Server Minimal Server: no Drivers de terceres parts: sí ``` ## Decisió final Instal·lem una Ubuntu Server 24.04 LTS estàndard, no minimal, amb teclat detectat automàticament i drivers de terceres parts activats. Aquesta decisió prioritza estabilitat i comoditat d’administració per sobre de tenir una instal·lació extremadament mínima. ## Estat del procés Un cop triades aquestes opcions, continuem cap a la configuració de xarxa de l’instal·lador. # Instal·lació d’Ubuntu Server 24.04 a la VM PeerTube ## 9. Configuració de xarxa de la VM Durant la instal·lació d’Ubuntu Server configurem la xarxa de la nova VM PeerTube. Assignem una IP fixa dins la mateixa xarxa on ja tenim el TrueNAS. ## Dades de xarxa conegudes El TrueNAS està a: ```text 192.168.100.101 ``` Per a la VM PeerTube assignem: ```text 192.168.100.111 ``` ## Decisió presa La VM PeerTube tindrà IP fixa: ```text 192.168.100.111 ``` Això permetrà que el CT Apache Reverse Proxy pugui apuntar sempre a la mateixa IP interna. També facilitarà el muntatge NFS cap al TrueNAS. ## Configuració recomanada A l’instal·lador d’Ubuntu Server, a la pantalla de xarxa, editem la interfície detectada i configurem IPv4 manual. Els valors serien: ```text IPv4 Method: Manual Subnet: 192.168.100.0/24 Address: 192.168.100.111 Gateway: 192.168.100.1 Name servers: 1.1.1.1, 8.8.8.8 Search domains: buit ``` ## Nota sobre el gateway El gateway probable és: ```text 192.168.100.1 ``` Això depèn de la teva xarxa real. Si el router/gateway de la xarxa 192.168.100.0/24 és un altre, cal posar aquell. ## Nota sobre DNS Podem posar DNS públics: ```text 1.1.1.1 8.8.8.8 ``` O bé un DNS intern si la xarxa en té un. Per començar, els DNS públics són suficients perquè la VM pugui descarregar paquets, imatges Docker i actualitzacions. ## Esquema de xarxa ```text TrueNAS IP: 192.168.100.101 Funció: emmagatzematge NFS per a la DATA de vídeo PeerTube VM IP: 192.168.100.111 Funció: host Docker amb PeerTube, PostgreSQL i Redis Apache Reverse Proxy CT Funció: HTTPS públic i proxy cap a PeerTube Backend previst: http://192.168.100.111:9000 ``` ## Resum de configuració ```text IP PeerTube VM: 192.168.100.111 Xarxa: 192.168.100.0/24 Gateway: 192.168.100.1 DNS: 1.1.1.1, 8.8.8.8 TrueNAS: 192.168.100.101 ``` ## Justificació Fem servir IP fixa perquè aquesta VM serà un servidor. Això evita que canviï la IP després d’un reinici i simplifica: - la configuració del proxy invers Apache; - el muntatge NFS amb TrueNAS; - les proves de connectivitat; - la documentació del desplegament; - el manteniment posterior. ## Comprovacions posteriors Quan Ubuntu ja estigui instal·lat, comprovarem la xarxa amb: ```bash root@peertube-vm:~# ip a ``` ```bash root@peertube-vm:~# ip route ``` ```bash root@peertube-vm:~# ping -c 4 192.168.100.101 ``` ```bash root@peertube-vm:~# ping -c 4 1.1.1.1 ``` ```bash root@peertube-vm:~# ping -c 4 google.com ``` ## Estat del procés Un cop configurada la xarxa amb la IP fixa `192.168.100.111`, continuem amb la configuració del proxy de l’instal·lador, si apareix. # Instal·lació d’Ubuntu Server 24.04 a la VM PeerTube ## 10. Configuració del disc durant la instal·lació Durant la instal·lació d’Ubuntu Server, l’assistent ens pregunta com volem particionar el disc. En aquest cas farem una instal·lació senzilla: ```text Tot el sistema en un únic disc virtual ``` Aquest disc és el que hem creat abans des de Proxmox per a la VM PeerTube. ## Per què pregunta per LVM? Ubuntu Server marca per defecte l’opció de fer servir **LVM** perquè és una forma flexible de gestionar volums de disc en Linux. LVM vol dir: ```text Logical Volume Manager ``` És una capa intermèdia entre el disc físic o virtual i els sistemes de fitxers. En lloc de crear particions rígides directament sobre el disc, Ubuntu crea: ```text Disc virtual → partició física → grup de volums LVM → volums lògics → sistema de fitxers ``` ## Opció que apareix marcada L’instal·lador sol mostrar una opció semblant a: ```text Set up this disk as an LVM group ``` o en català: ```text Configura aquest disc com a grup LVM ``` Aquesta opció ve marcada per defecte. ## La deixem marcada? Sí. Per aquesta VM podem deixar LVM activat. ## Decisió presa Fem servir: ```text Use an entire disk: sí Set up this disk as an LVM group: sí Encrypt the LVM group with LUKS: no ``` ## Per què deixem LVM activat? LVM ens pot anar bé perquè: - és el valor per defecte d’Ubuntu Server; - és estable i molt habitual en servidors Linux; - permet ampliar volums més fàcilment en el futur; - encaixa bé amb una VM que podria créixer; - no ens complica gaire l’administració normal del sistema. ## Per què NO activem xifrat LUKS? No activem: ```text Encrypt the LVM group with LUKS ``` Per aquesta VM no volem xifrat de disc perquè: - complicaria l’arrencada automàtica; - podria demanar contrasenya al boot; - no és necessari per a aquest laboratori; - el Proxmox ja controla l’accés al disc virtual; - la DATA gran estarà al TrueNAS, no en aquest disc. ## Tot en un disc Triem el disc virtual sencer. L’esquema conceptual queda així: ```text Disc virtual de la VM ├── partició EFI ├── partició /boot └── LVM └── volum root / ``` ## Important sobre la mida del volum root A vegades Ubuntu Server, quan fa servir LVM, no assigna automàticament tot l’espai disponible al volum root `/`. Pot crear un volum root més petit i deixar espai lliure dins el grup LVM. Per tant, a la pantalla de resum del particionament cal mirar si el volum `/` ocupa gairebé tot el disc disponible. ## Què volem en aquesta VM? Volem que el sistema tingui disponible pràcticament tot el disc intern de la VM. Per tant, si el disc és de: ```text 100 GB ``` ens interessa que el volum principal `/` tingui una mida propera a: ```text 100 GB ``` descomptant EFI, `/boot` i petites reserves. ## Si Ubuntu deixa espai lliure dins LVM Si a la pantalla de resum veiem alguna cosa com: ```text free space dins ubuntu-vg ``` o que `/` només té una part del disc, podem editar el volum root i ampliar-lo durant la instal·lació. L’objectiu és evitar que el sistema quedi amb, per exemple, només 50 GB útils mentre la resta queda sense assignar. ## Resum de configuració del disc ```text Use an entire disk: sí Disk selected: disc virtual de la VM Set up this disk as an LVM group: sí Encrypt with LUKS: no Filesystem principal: ext4 Mount point principal: / ``` ## Decisió final Instal·lem Ubuntu Server fent servir tot el disc virtual i mantenint LVM activat. No activem xifrat. Aquesta és una configuració estàndard, estable i flexible per a una VM de servidor. ## Justificació per al projecte PeerTube Aquest disc local servirà per: - Ubuntu Server; - Docker; - imatges Docker; - volums interns; - PostgreSQL; - Redis; - configuració; - logs. La DATA gran de vídeo no dependrà d’aquest disc, perquè anirà muntada des del TrueNAS. ## Repartiment previst de dades ```text Disc local VM PeerTube ├── sistema Ubuntu ├── Docker ├── PostgreSQL ├── Redis ├── configuració └── logs TrueNAS 192.168.100.101 ├── vídeos originals ├── vídeos transcodificats ├── HLS / streaming playlists ├── thumbnails ├── previews └── imports ``` ## Comprovació posterior Quan el sistema ja estigui instal·lat, podrem veure l’estat del disc amb: ```bash root@peertube-vm:~# lsblk ``` ```bash root@peertube-vm:~# df -h ``` I si calgués revisar LVM: ```bash root@peertube-vm:~# vgs ``` ```bash root@peertube-vm:~# lvs ``` ## Estat del procés Un cop confirmat el particionament, l’instal·lador avisarà que escriurà els canvis al disc. Acceptem només si el disc seleccionat és el disc virtual de la VM PeerTube. # Instal·lació d’Ubuntu Server 24.04 a la VM PeerTube ## 11. Primer reinici de la VM Un cop acabada la instal·lació d’Ubuntu Server, l’instal·lador demana reiniciar la màquina. En aquest punt pot passar que la VM torni a arrencar des de la ISO d’instal·lació si encara està muntada com a CD/DVD. Per evitar-ho, hem tret la ISO de la unitat virtual abans de reiniciar la VM. ## Acció realitzada A Proxmox hem anat a la configuració de la VM i hem retirat la ISO d’instal·lació. La ruta és: ```text VM PeerTube → Hardware → CD/DVD Drive → Edit ``` I hem deixat la unitat sense ISO muntada: ```text Do not use any media ``` o equivalent. ## Per què cal treure la ISO? Durant la instal·lació, la VM arrenca des de: ```text ubuntu-24.04-live-server-amd64.iso ``` Quan Ubuntu ja està instal·lat al disc virtual, volem que la VM arrenqui des del disc i no torni a entrar a l’instal·lador. Per això retirem la ISO o canviem l’ordre d’arrencada. ## Decisió presa Després de completar la instal·lació: ```text ISO retirada de la unitat CD/DVD virtual VM reiniciada Arrencada des del disc virtual ``` ## Comprovació a Proxmox També podem revisar l’ordre d’arrencada: ```text VM PeerTube → Options → Boot Order ``` L’ordre correcte hauria de prioritzar el disc de la VM: ```text scsi0 ``` I deixar el CD/DVD sense prioritat, o sense ISO muntada. ## Resultat esperat Després del reinici, la VM hauria d’arrencar directament a Ubuntu Server i mostrar una pantalla de login semblant a: ```text Ubuntu 24.04 LTS peertube-vm tty1 peertube-vm login: ``` ## Primera entrada al sistema Entrem amb l’usuari creat durant la instal·lació. Si l’usuari creat és, per exemple: ```text xab ``` farem login amb aquest usuari. Després, podem passar a root amb: ```bash xab@peertube-vm:~$ sudo -i ``` El prompt passarà a ser: ```bash root@peertube-vm:~# ``` ## Primeres comprovacions Un cop dins la VM, comprovem que el sistema ha arrencat correctament. ### Comprovar hostname ```bash root@peertube-vm:~# hostname ``` Resultat esperat: ```text peertube-vm ``` ### Comprovar IP ```bash root@peertube-vm:~# ip a ``` Hauríem de veure la IP configurada: ```text 192.168.100.111 ``` ### Comprovar ruta per defecte ```bash root@peertube-vm:~# ip route ``` Hauríem de veure una ruta semblant a: ```text default via 192.168.100.1 ``` ### Comprovar connexió amb TrueNAS ```bash root@peertube-vm:~# ping -c 4 192.168.100.101 ``` Si respon, la VM PeerTube veu correctament el TrueNAS. ### Comprovar sortida a internet ```bash root@peertube-vm:~# ping -c 4 1.1.1.1 ``` ### Comprovar DNS ```bash root@peertube-vm:~# ping -c 4 google.com ``` Si aquest últim funciona, la xarxa i el DNS estan correctes. ## Actualització inicial del sistema Un cop comprovat que la xarxa funciona, actualitzem paquets. ```bash root@peertube-vm:~# apt update ``` ```bash root@peertube-vm:~# apt upgrade -y ``` ## Instal·lació del Qemu Guest Agent Com que a Proxmox hem activat l’opció: ```text Qemu Agent: enabled ``` ara instal·lem el servei dins d’Ubuntu. ```bash root@peertube-vm:~# apt install -y qemu-guest-agent ``` L’activem i l’arranquem: ```bash root@peertube-vm:~# systemctl enable --now qemu-guest-agent ``` Comprovem l’estat: ```bash root@peertube-vm:~# systemctl status qemu-guest-agent ``` ## Instal·lació d’eines bàsiques Instal·lem algunes eines útils per administrar la VM. ```bash root@peertube-vm:~# apt install -y curl wget git vim nano htop net-tools ca-certificates gnupg lsb-release ``` ## Instal·lació de suport NFS Com que aquesta VM haurà de muntar dades des del TrueNAS, instal·lem el client NFS. ```bash root@peertube-vm:~# apt install -y nfs-common ``` ## Resum de la fase actual ```text Ubuntu Server 24.04 instal·lat ISO retirada de la VM Arrencada des del disc virtual IP prevista: 192.168.100.111 TrueNAS: 192.168.100.101 Qemu Guest Agent pendent o instal·lat NFS client pendent o instal·lat ``` ## Decisió documentada Després de la instal·lació, retirem la ISO perquè la VM arrenqui directament des del disc virtual. Aquesta és una acció normal després d’instal·lar qualsevol sistema operatiu en una VM. ## Estat del procés El següent pas serà deixar el sistema base preparat: ```text actualitzar Ubuntu activar qemu-guest-agent comprovar xarxa instal·lar eines bàsiques instal·lar client NFS preparar Docker ``` # Configuració d’accés SSH amb clau pública ## 12. Objectiu Volem poder accedir per SSH sense contrasenya a: ```text VM PeerTube Ubuntu: 192.168.100.111 Node Proxmox: base ``` La idea és posar la nostra clau pública SSH als fitxers `authorized_keys` corresponents. Quan l’accés per clau funcioni correctament, desactivarem el login SSH per contrasenya. ## 13. Escenari Treballarem amb tres màquines: ```text Ordinador personal → lloc on ja tenim la clau privada i pública SSH Proxmox → node base VM PeerTube → Ubuntu Server 24.04 → IP: 192.168.100.111 ``` ## 14. Comprovar la clau pública al nostre ordinador Al nostre ordinador local, comprovem si ja tenim clau pública SSH. ```bash xab@host-xab:~$ ls -lh ~/.ssh/ ``` Normalment veurem fitxers semblants a: ```text id_ed25519 id_ed25519.pub known_hosts ``` La clau pública és el fitxer acabat en `.pub`. Per veure-la: ```bash xab@host-xab:~$ cat ~/.ssh/id_ed25519.pub ``` La sortida serà una línia llarga semblant a: ```text ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... xab@host-xab ``` Aquesta línia sencera és la que hem de copiar dins dels fitxers `authorized_keys` dels servidors. ## 15. Si no tenim clau SSH creada Si no existís cap clau, en creem una. ```bash xab@host-xab:~$ ssh-keygen -t ed25519 -C "xab@host-xab" ``` Acceptem la ruta per defecte: ```text /home/xab/.ssh/id_ed25519 ``` Podem posar passphrase o deixar-la buida. Per a més seguretat, és millor posar passphrase. Per a laboratori, es pot deixar buida si volem accés directe. ## 16. Copiar la clau pública a la VM PeerTube La manera més còmoda és fer servir `ssh-copy-id`. Si l’usuari creat durant la instal·lació d’Ubuntu és `xab`, fem: ```bash xab@host-xab:~$ ssh-copy-id xab@192.168.100.111 ``` Ens demanarà la contrasenya de l’usuari `xab` de la VM. Després provem l’accés: ```bash xab@host-xab:~$ ssh xab@192.168.100.111 ``` Si entra sense demanar la contrasenya de l’usuari remot, la clau ja funciona. ## 17. Revisar permisos a la VM PeerTube Un cop dins la VM PeerTube: ```bash xab@peertube-vm:~$ sudo -i ``` Comprovem la carpeta `.ssh` de l’usuari: ```bash root@peertube-vm:~# ls -ld /home/xab/.ssh ``` ```bash root@peertube-vm:~# ls -lh /home/xab/.ssh/authorized_keys ``` Els permisos correctes han de ser: ```text /home/xab/.ssh 700 /home/xab/.ssh/authorized_keys 600 ``` Els deixem correctes explícitament: ```bash root@peertube-vm:~# chown -R xab:xab /home/xab/.ssh ``` ```bash root@peertube-vm:~# chmod 700 /home/xab/.ssh ``` ```bash root@peertube-vm:~# chmod 600 /home/xab/.ssh/authorized_keys ``` ## 18. Crear un àlies SSH per entrar més còmode a la VM Al nostre ordinador local editem el fitxer de configuració SSH: ```bash xab@host-xab:~$ nano ~/.ssh/config ``` Afegim: ```sshconfig Host peertube-vm HostName 192.168.100.111 User xab IdentityFile ~/.ssh/id_ed25519 ``` Protegim el fitxer: ```bash xab@host-xab:~$ chmod 600 ~/.ssh/config ``` Ara ja podem entrar amb: ```bash xab@host-xab:~$ ssh peertube-vm ``` ## 19. Copiar la clau pública al node Proxmox També volem poder entrar al Proxmox sense contrasenya. Si volem entrar com a `root` al node `base`, fem: ```bash xab@host-xab:~$ ssh-copy-id root@IP_DEL_PROXMOX ``` Per exemple, si el Proxmox fos `192.168.100.10`: ```bash xab@host-xab:~$ ssh-copy-id root@192.168.100.10 ``` Després provem: ```bash xab@host-xab:~$ ssh root@192.168.100.10 ``` Si entra sense demanar contrasenya, ja funciona. ## 20. Revisar permisos al Proxmox Un cop dins del node Proxmox: ```bash root@base:~# ls -ld /root/.ssh ``` ```bash root@base:~# ls -lh /root/.ssh/authorized_keys ``` Els permisos correctes són: ```text /root/.ssh 700 /root/.ssh/authorized_keys 600 ``` Els deixem correctes explícitament: ```bash root@base:~# chown -R root:root /root/.ssh ``` ```bash root@base:~# chmod 700 /root/.ssh ``` ```bash root@base:~# chmod 600 /root/.ssh/authorized_keys ``` ## 21. Crear un àlies SSH per al Proxmox Al nostre ordinador local: ```bash xab@host-xab:~$ nano ~/.ssh/config ``` Afegim també: ```sshconfig Host proxmox-base HostName 192.168.100.10 User root IdentityFile ~/.ssh/id_ed25519 ``` Canviem `192.168.100.10` per la IP real del node Proxmox. Ara podrem entrar amb: ```bash xab@host-xab:~$ ssh proxmox-base ``` ## 22. Fitxer SSH config complet d’exemple El fitxer local podria quedar així: ```sshconfig Host peertube-vm HostName 192.168.100.111 User xab IdentityFile ~/.ssh/id_ed25519 Host proxmox-base HostName 192.168.100.10 User root IdentityFile ~/.ssh/id_ed25519 ``` Amb això tindrem dos accessos curts: ```bash xab@host-xab:~$ ssh peertube-vm ``` ```bash xab@host-xab:~$ ssh proxmox-base ``` ## 23. Alternativa manual si no fem servir ssh-copy-id Si `ssh-copy-id` no funciona, podem fer-ho manualment. Primer copiem la clau pública del nostre ordinador: ```bash xab@host-xab:~$ cat ~/.ssh/id_ed25519.pub ``` Copiem tota la línia. Després, a la VM PeerTube: ```bash xab@peertube-vm:~$ mkdir -p ~/.ssh ``` ```bash xab@peertube-vm:~$ nano ~/.ssh/authorized_keys ``` Enganxem la clau pública en una sola línia. Després ajustem permisos: ```bash xab@peertube-vm:~$ chmod 700 ~/.ssh ``` ```bash xab@peertube-vm:~$ chmod 600 ~/.ssh/authorized_keys ``` En el cas de Proxmox, com a root: ```bash root@base:~# mkdir -p /root/.ssh ``` ```bash root@base:~# nano /root/.ssh/authorized_keys ``` Enganxem la clau pública i ajustem permisos: ```bash root@base:~# chmod 700 /root/.ssh ``` ```bash root@base:~# chmod 600 /root/.ssh/authorized_keys ``` ```bash root@base:~# chown -R root:root /root/.ssh ``` ## 24. Comprovar que l’accés per clau funciona Des del nostre ordinador local: ```bash xab@host-xab:~$ ssh peertube-vm ``` I també: ```bash xab@host-xab:~$ ssh proxmox-base ``` Si tots dos accessos funcionen sense demanar la contrasenya de l’usuari remot, ja podem passar a endurir SSH. ## 25. Desactivar login SSH per contrasenya a la VM PeerTube Primer fem una còpia del fitxer de configuració SSH. ```bash root@peertube-vm:~# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak ``` Editem el fitxer: ```bash root@peertube-vm:~# nano /etc/ssh/sshd_config ``` Busquem o afegim aquestes línies: ```text PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes PermitRootLogin no ``` En aquesta VM no cal permetre login directe de root. Entrem com a `xab` i, si cal, fem: ```bash xab@peertube-vm:~$ sudo -i ``` Comprovem la configuració abans de reiniciar el servei: ```bash root@peertube-vm:~# sshd -t ``` Si no mostra cap error, reiniciem SSH: ```bash root@peertube-vm:~# systemctl restart ssh ``` ## 26. Desactivar login SSH per contrasenya al Proxmox Al Proxmox cal anar amb més cura, perquè és el node host. Primer, abans de tocar res, deixem oberta una sessió SSH funcional. Després fem còpia de seguretat: ```bash root@base:~# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak ``` Editem: ```bash root@base:~# nano /etc/ssh/sshd_config ``` Configurem: ```text PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes PermitRootLogin prohibit-password ``` Aquesta opció permet login de root només amb clau pública, però no amb contrasenya: ```text PermitRootLogin prohibit-password ``` Comprovem sintaxi: ```bash root@base:~# sshd -t ``` Si no dona cap error: ```bash root@base:~# systemctl restart ssh ``` ## 27. Prova de seguretat després dels canvis Sense tancar la sessió SSH que ja tenim oberta, obrim una nova terminal local i provem: ```bash xab@host-xab:~$ ssh peertube-vm ``` I també: ```bash xab@host-xab:~$ ssh proxmox-base ``` Si entren correctament, l’accés per clau funciona. Ara provem que la contrasenya ja no serveix. Podem forçar SSH a no usar clau: ```bash xab@host-xab:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no peertube-vm ``` Hauria de fallar. També amb Proxmox: ```bash xab@host-xab:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no proxmox-base ``` També hauria de fallar. ## 28. Resum de decisió Configurem l’accés SSH amb clau pública per a: ```text VM PeerTube: 192.168.100.111 Node Proxmox: base ``` Afegim àlies SSH locals: ```text peertube-vm proxmox-base ``` Un cop validat l’accés per clau, desactivem l’autenticació per contrasenya. ## 29. Estat final esperat ```text ssh peertube-vm → entra a la VM Ubuntu sense contrasenya remota ssh proxmox-base → entra al node Proxmox sense contrasenya remota PasswordAuthentication → desactivat PubkeyAuthentication → activat ``` ## 30. Notes importants No s’ha de desactivar el login per contrasenya fins haver comprovat que l’accés amb clau funciona. És recomanable mantenir una sessió SSH oberta mentre es reinicia el servei SSH, per evitar quedar-nos fora en cas d’error de configuració. En la VM PeerTube desactivem el login directe de root. En el node Proxmox permetem root només amb clau pública, perquè és habitual administrar Proxmox com a root per SSH. # SSH amb ProxyJump: la clau local i la clau del Proxmox ## Dubte Quan fem: ```bash xab@host-xab:~$ ssh -J root@IP_DEL_PROXMOX xab@192.168.100.111 ``` pot semblar que el Proxmox entra al PeerTube “amb la seva clau”, però no és exactament així. ## Explicació curta Amb `ProxyJump`, el Proxmox fa de pont. El camí és: ```text ordinador local → SSH cap al Proxmox → túnel cap al PeerTube ``` Però l’autenticació final contra el PeerTube la fa el client SSH del teu ordinador local. Per això el PeerTube ha de tenir autoritzada la clau pública del teu ordinador local. ## Quan serien la mateixa clau? Serien la mateixa clau només si el fitxer de clau privada és el mateix en tots dos llocs. Per exemple, si tant al teu ordinador local com al Proxmox existeix exactament aquesta mateixa clau privada: ```text ~/.ssh/id_ed25519 ``` Això no és habitual ni recomanable. El més normal és tenir: ```text Ordinador local: /home/xab/.ssh/id_ed25519 /home/xab/.ssh/id_ed25519.pub Proxmox: /root/.ssh/id_ed25519 /root/.ssh/id_ed25519.pub ``` Aquestes dues claus poden tenir el mateix nom, però no són la mateixa clau. ## Com comprovar si són la mateixa Al teu ordinador local: ```bash xab@host-xab:~$ ssh-keygen -lf ~/.ssh/id_ed25519.pub ``` Al Proxmox: ```bash root@base:~# ssh-keygen -lf ~/.ssh/id_ed25519.pub ``` Si surt el mateix fingerprint, són la mateixa clau. Si surt diferent fingerprint, són claus diferents. Exemple de fingerprint: ```text 256 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xab@host-xab (ED25519) ``` ## Què ha passat en el teu cas Tu has fet: ```text local → proxmox ``` i funciona sense contrasenya. També has fet: ```text proxmox → peer ``` i funciona, perquè el PeerTube té la clau pública del Proxmox. Però amb `ProxyJump` fas: ```text local → proxmox → peer ``` i el PeerTube espera la clau pública del local, no la del Proxmox. Per això encara et demana password al segon salt. ## Solució correcta Des del teu ordinador local, copia la teva clau pública local al PeerTube passant pel Proxmox: ```bash xab@host-xab:~$ ssh-copy-id -i ~/.ssh/id_ed25519.pub -o ProxyJump=root@IP_DEL_PROXMOX xab@192.168.100.111 ``` Després prova: ```bash xab@host-xab:~$ ssh -J root@IP_DEL_PROXMOX xab@192.168.100.111 ``` ## Resum No importa que el Proxmox ja pugui entrar al PeerTube. Perquè funcioni `ssh -J`, el PeerTube també ha d’acceptar la clau pública del teu ordinador local. La clau pública del Proxmox i la clau pública del teu ordinador local només són la mateixa si tenen el mateix fingerprint. # Desplegament de PeerTube amb Docker sobre VM Ubuntu ## 1. Objectiu del desplegament Disposem d’una VM Ubuntu Server 24.04 amb IP privada: ```text 192.168.100.111 ``` Disposem també d’un TrueNAS amb IP: ```text 192.168.100.101 ``` Al TrueNAS tenim preparada la ruta: ```text /mnt/AV/VM ``` L’objectiu és desplegar PeerTube amb Docker dins la VM Ubuntu, però separant clarament les dades: ```text VM Ubuntu PeerTube ├── Docker ├── Docker Compose ├── PeerTube ├── PostgreSQL ├── Redis ├── configuració ├── logs └── volums interns petits TrueNAS └── DATA gran de PeerTube ├── vídeos originals ├── vídeos transcodificats ├── HLS / streaming playlists ├── thumbnails ├── previews ├── imports ├── captions ├── storyboards └── altres fitxers audiovisuals grans ``` El proxy invers i HTTPS no es faran dins aquesta VM. Continuaran en un CT separat amb Apache. ## 2. Arquitectura final ```text Internet | v CT Apache Reverse Proxy | | HTTP intern cap a PeerTube v VM Ubuntu Server 24.04 192.168.100.111 | | NFS v TrueNAS 192.168.100.101 ``` ## 3. Decisió sobre els volums El directori oficial `./docker-volume/data` de PeerTube és el que conté la part grossa de dades de l’aplicació. Per tant, en el nostre cas aquest directori no viurà realment al disc local de la VM, sinó que serà un enllaç cap al muntatge NFS del TrueNAS. La separació serà: ```text Local dins la VM: /opt/peertube/docker-volume/db /opt/peertube/docker-volume/redis /opt/peertube/docker-volume/config /opt/peertube/docker-volume/opendkim /opt/peertube/docker-compose.yml /opt/peertube/.env Muntat des del TrueNAS: /mnt/truenas-peertube/data ``` I després: ```text /opt/peertube/docker-volume/data -> /mnt/truenas-peertube/data ``` ## 4. Preparació del TrueNAS Al TrueNAS ja existeix: ```bash root@truenas:~# ls -lna /mnt/AV/VM ``` Sortida actual: ```text total 9 drwxr-xr-x 2 0 0 2 Jun 5 21:32 . drwxr-xr-x 8 0 0 8 Jun 5 21:32 .. ``` Creem una carpeta específica per a PeerTube: ```bash root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data ``` I una estructura inicial més llegible: ```bash root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/videos root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/original-video-files root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/streaming-playlists root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/thumbnails root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/previews root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/imports root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/captions root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/storyboards root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/tmp ``` De moment podem deixar propietari root i permisos oberts només per provar el muntatge. ```bash root@truenas:~# chmod -R 775 /mnt/AV/VM/peertube ``` ## 5. Export NFS des del TrueNAS Des de la GUI de TrueNAS, exportem per NFS: ```text Path: /mnt/AV/VM/peertube Allowed hosts/networks: 192.168.100.111 Maproot User: root Maproot Group: root ``` Per començar, ho fem simple i restringit a la VM PeerTube. La VM Ubuntu muntarà aquesta exportació a: ```text /mnt/truenas-peertube ``` ## 6. Preparació de la VM Ubuntu Entrem a la VM PeerTube: ```bash xab@host-xab:~$ ssh peertube-vm ``` Passem a root: ```bash xab@peertube-vm:~$ sudo -i ``` Actualitzem el sistema: ```bash root@peertube-vm:~# apt update root@peertube-vm:~# apt upgrade -y ``` Instal·lem eines bàsiques: ```bash root@peertube-vm:~# apt install -y ca-certificates curl gnupg git nano vim htop nfs-common ufw ``` ## 7. Instal·lació de Docker Engine i Docker Compose Plugin Docker recomana instal·lar Docker Engine des del seu repositori `apt` oficial; Ubuntu 24.04 LTS `noble` està suportat oficialment per Docker Engine. :contentReference[oaicite:2]{index=2} Creem el directori de claus: ```bash root@peertube-vm:~# install -m 0755 -d /etc/apt/keyrings ``` Descarreguem la clau oficial de Docker: ```bash root@peertube-vm:~# curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc ``` Assignem permisos: ```bash root@peertube-vm:~# chmod a+r /etc/apt/keyrings/docker.asc ``` Afegim el repositori oficial: ```bash root@peertube-vm:~# tee /etc/apt/sources.list.d/docker.sources < docker-compose.yml ``` Descarreguem el fitxer `.env` oficial de producció: ```bash root@peertube-vm:/opt/peertube# curl https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/.env > .env ``` La documentació oficial indica explícitament aquests dos fitxers com a base del desplegament Docker de PeerTube. :contentReference[oaicite:3]{index=3} ## 11. Creació dels volums locals Creem els directoris locals que sí que volem dins la VM: ```bash root@peertube-vm:/opt/peertube# mkdir -p docker-volume/db root@peertube-vm:/opt/peertube# mkdir -p docker-volume/redis root@peertube-vm:/opt/peertube# mkdir -p docker-volume/config root@peertube-vm:/opt/peertube# mkdir -p docker-volume/opendkim/keys ``` Creem també el directori pare de dades: ```bash root@peertube-vm:/opt/peertube# mkdir -p docker-volume ``` Enllacem el directori de DATA gran cap al TrueNAS: ```bash root@peertube-vm:/opt/peertube# ln -s /mnt/truenas-peertube/data docker-volume/data ``` Comprovem: ```bash root@peertube-vm:/opt/peertube# ls -lna docker-volume ``` Hauríem de veure: ```text data -> /mnt/truenas-peertube/data db redis config opendkim ``` ## 12. Adaptació del docker-compose.yml El `docker-compose.yml` oficial porta serveis de: ```text webserver certbot webserver-reloader peertube postgres redis postfix ``` Nosaltres NO volem fer servir dins aquesta VM: ```text webserver certbot webserver-reloader ``` perquè el proxy invers i HTTPS els farà el CT Apache extern. Per tant, editem el fitxer: ```bash root@peertube-vm:/opt/peertube# nano docker-compose.yml ``` Cal comentar o eliminar aquests serveis: ```yaml webserver: certbot: webserver-reloader: ``` També cal modificar el servei `peertube` perquè publiqui el port intern `9000` cap a la VM: ```yaml ports: - "9000:9000" - "1935:1935" ``` Si no volem funcionalitat live RTMP, podem deixar comentat el port `1935`. Per a una primera prova, jo deixaria: ```yaml ports: - "9000:9000" ``` I si després volem directes: ```yaml ports: - "1935:1935" - "9000:9000" ``` ## 13. Volums que han de quedar al compose El servei `peertube` ha de mantenir: ```yaml volumes: - ./docker-volume/data:/data - ./docker-volume/config:/config ``` El servei `postgres` ha de mantenir: ```yaml volumes: - ./docker-volume/db:/var/lib/postgresql/data ``` El servei `redis` ha de mantenir: ```yaml volumes: - ./docker-volume/redis:/data ``` El servei `postfix` ha de mantenir: ```yaml volumes: - ./docker-volume/opendkim/keys:/etc/opendkim/keys ``` Això ens dona exactament la separació volguda: ```text /data de PeerTube → TrueNAS /config de PeerTube → local VM PostgreSQL → local VM Redis → local VM OpenDKIM → local VM ``` ## 14. Adaptació del fitxer .env Editem el fitxer `.env`: ```bash root@peertube-vm:/opt/peertube# nano .env ``` Cal substituir els valors de plantilla: ```text ``` La documentació oficial indica que aquests valors s’han de substituir al `.env`. :contentReference[oaicite:4]{index=4} Exemple conceptual: ```env POSTGRES_USER=peertube POSTGRES_PASSWORD=CONTRASENYA_LLARGA_GENERADA POSTGRES_DB=peertube_prod PEERTUBE_WEBSERVER_HOSTNAME=video.exemple.cat PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true PEERTUBE_ADMIN_EMAIL=admin@exemple.cat PEERTUBE_SECRET=SECRET_LLARG_GENERAT PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "192.168.100.0/24"] ``` ## 15. Generar contrasenyes i secret Generem una contrasenya per PostgreSQL: ```bash root@peertube-vm:/opt/peertube# openssl rand -base64 32 ``` Generem el secret de PeerTube: ```bash root@peertube-vm:/opt/peertube# openssl rand -hex 32 ``` Aquests valors s’enganxen dins el fitxer `.env`. ## 16. Important sobre el domini El domini triat ha d’anar sense `https://`. Correcte: ```text video.exemple.cat ``` Incorrecte: ```text https://video.exemple.cat ``` PeerTube ha de saber que cap a fora treballa amb HTTPS, encara que internament el proxy Apache li parli per HTTP. Per això: ```env PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true ``` I el backend intern serà: ```text http://192.168.100.111:9000 ``` ## 17. Primera arrencada Des de `/opt/peertube`: ```bash root@peertube-vm:/opt/peertube# docker compose pull ``` Arrenquem: ```bash root@peertube-vm:/opt/peertube# docker compose up -d ``` Mirem contenidors: ```bash root@peertube-vm:/opt/peertube# docker compose ps ``` Mirem logs: ```bash root@peertube-vm:/opt/peertube# docker compose logs -f peertube ``` ## 18. Obtenir o reiniciar la contrasenya de root de PeerTube La documentació oficial indica que podem obtenir la contrasenya inicial als logs o reiniciar-la amb una ordre dins del contenidor. :contentReference[oaicite:5]{index=5} Per buscar-la als logs: ```bash root@peertube-vm:/opt/peertube# docker compose logs peertube | grep -A1 root ``` O per reiniciar-la manualment: ```bash root@peertube-vm:/opt/peertube# docker compose exec -u peertube peertube npm run reset-password -- -u root ``` ## 19. Prova local des de la VM Comprovem que PeerTube escolta al port 9000: ```bash root@peertube-vm:/opt/peertube# ss -lntp | grep 9000 ``` Provem amb curl: ```bash root@peertube-vm:/opt/peertube# curl -I http://127.0.0.1:9000 ``` També des del Proxmox o des del CT Apache: ```bash root@base:~# curl -I http://192.168.100.111:9000 ``` ## 20. Proxy invers Apache extern Al CT Apache, el backend haurà d’apuntar a: ```text http://192.168.100.111:9000 ``` El virtualhost públic farà: ```text https://DOMINI_TRIAT → proxy cap a http://192.168.100.111:9000 ``` Aquesta part la farem després des del CT Apache. ## 21. Resum de decisions ```text VM Ubuntu PeerTube IP: 192.168.100.111 Funció: host Docker PeerTube TrueNAS IP: 192.168.100.101 Ruta: /mnt/AV/VM/peertube Funció: DATA gran de PeerTube Proxy Apache Funció: HTTPS públic i reverse proxy Backend: http://192.168.100.111:9000 ``` ## 22. Separació final de dades ```text Local VM: /opt/peertube/docker-volume/db → PostgreSQL /opt/peertube/docker-volume/redis → Redis /opt/peertube/docker-volume/config → configuració PeerTube /opt/peertube/.env → variables del desplegament /opt/peertube/docker-compose.yml → definició del servei TrueNAS: /mnt/AV/VM/peertube/data → vídeos originals → transcodificats → HLS → thumbnails → previews → imports → captions → storyboards ``` ## 23. Estat esperat Quan tot funcioni, aquests comandos haurien de donar resultat correcte: ```bash root@peertube-vm:/opt/peertube# docker compose ps ``` ```bash root@peertube-vm:/opt/peertube# curl -I http://127.0.0.1:9000 ``` ```bash root@base:~# curl -I http://192.168.100.111:9000 ``` ```bash root@peertube-vm:/opt/peertube# df -h | grep truenas ``` ```bash root@peertube-vm:/opt/peertube# ls -lna docker-volume/data ``` # Desplegament de PeerTube: fase 1 ## Ordre de treball Abans de tocar el `docker-compose.yml` de PeerTube, deixem preparada la base del sistema. L’ordre correcte serà: ```text 1. Preparar l’export NFS al TrueNAS 2. Muntar NFS a la VM Ubuntu 3. Fer prova d’escriptura contra el TrueNAS 4. Instal·lar Docker Engine 5. Instal·lar Docker Compose Plugin 6. Descarregar els fitxers oficials de PeerTube 7. Adaptar el desplegament al nostre escenari ``` ## Objectiu de la fase 1 Deixar validat que la VM Ubuntu pot: - accedir al TrueNAS; - muntar el directori remot; - escriure dades al directori remot; - executar Docker correctament; - executar `docker compose`. ## Separació de dades La decisió principal del desplegament és aquesta: ```text VM Ubuntu PeerTube → sistema → Docker → PostgreSQL → Redis → configuració → logs → fitxers del compose TrueNAS → vídeos originals → vídeos transcodificats → HLS → thumbnails → previews → imports → captions → storyboards ``` ## Següent pas immediat Començarem preparant la carpeta de PeerTube dins del TrueNAS: ```bash root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data ``` I després prepararem les subcarpetes de dades grans: ```bash root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/videos root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/original-video-files root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/streaming-playlists root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/thumbnails root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/previews root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/imports root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/captions root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/storyboards root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/tmp ``` ## Comprovació Després comprovem l’estructura: ```bash root@truenas:~# find /mnt/AV/VM/peertube -maxdepth 3 -type d | sort ``` Resultat esperat: ```text /mnt/AV/VM/peertube /mnt/AV/VM/peertube/data /mnt/AV/VM/peertube/data/captions /mnt/AV/VM/peertube/data/imports /mnt/AV/VM/peertube/data/original-video-files /mnt/AV/VM/peertube/data/previews /mnt/AV/VM/peertube/data/storyboards /mnt/AV/VM/peertube/data/streaming-playlists /mnt/AV/VM/peertube/data/thumbnails /mnt/AV/VM/peertube/data/tmp /mnt/AV/VM/peertube/data/videos ``` ## Permisos provisionals Per començar i validar el muntatge NFS, deixem permisos d’escriptura de grup: ```bash root@truenas:~# chmod -R 775 /mnt/AV/VM/peertube ``` ## Nota Aquesta configuració de permisos és inicial. Quan sapiguem exactament amb quin UID/GID escriu el contenidor de PeerTube, ajustarem els propietaris de manera més fina. El punt important ara és validar: ```text VM Ubuntu → NFS → TrueNAS ``` # Desplegament de PeerTube: fase 1 ## 1. Preparació de la carpeta de dades al TrueNAS El TrueNAS farà de magatzem per a la DATA gran de PeerTube. En aquesta fase preparem el directori on viuran les dades audiovisuals: ```text /mnt/AV/VM/peertube/data ``` Aquest directori contindrà vídeos originals, vídeos transcodificats, HLS, miniatures, previews i imports. ## 2. Crear l’estructura de directoris al TrueNAS Entrem al TrueNAS com a root i creem l’estructura base: ```bash root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data ``` Creem les carpetes principals de dades: ```bash root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/videos root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/original-video-files root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/streaming-playlists root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/thumbnails root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/previews root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/imports root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/captions root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/storyboards root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data/tmp ``` ## 3. Comprovar l’estructura creada Comprovem que les carpetes existeixen: ```bash root@truenas:~# find /mnt/AV/VM/peertube -maxdepth 3 -type d | sort ``` Resultat esperat: ```text /mnt/AV/VM/peertube /mnt/AV/VM/peertube/data /mnt/AV/VM/peertube/data/captions /mnt/AV/VM/peertube/data/imports /mnt/AV/VM/peertube/data/original-video-files /mnt/AV/VM/peertube/data/previews /mnt/AV/VM/peertube/data/storyboards /mnt/AV/VM/peertube/data/streaming-playlists /mnt/AV/VM/peertube/data/thumbnails /mnt/AV/VM/peertube/data/tmp /mnt/AV/VM/peertube/data/videos ``` ## 4. Permisos provisionals al TrueNAS Per a la primera prova de muntatge NFS, deixem permisos amplis però no completament oberts: ```bash root@truenas:~# chmod -R 775 /mnt/AV/VM/peertube ``` Comprovem permisos i propietaris numèrics: ```bash root@truenas:~# ls -lna /mnt/AV/VM ``` ```bash root@truenas:~# ls -lna /mnt/AV/VM/peertube ``` ```bash root@truenas:~# ls -lna /mnt/AV/VM/peertube/data ``` ## 5. Decisió sobre permisos De moment mantenim propietari `root:root`. Aquesta és una decisió provisional. Quan tinguem PeerTube arrencat i sapiguem exactament amb quin UID/GID escriu dins del contenidor, ajustarem els permisos de manera més fina. L’objectiu ara és comprovar que la VM Ubuntu pot muntar i escriure al directori exportat. ## 6. Export NFS des de la GUI de TrueNAS Ara cal crear l’exportació NFS des de la interfície web de TrueNAS. Ruta aproximada: ```text Shares → Unix Shares (NFS) → Add ``` Configurem: ```text Path: /mnt/AV/VM/peertube Description: PeerTube data for Ubuntu VM Enabled: yes ``` Restricció recomanada: ```text Allowed hosts: 192.168.100.111 ``` Això limita l’accés NFS només a la VM PeerTube. ## 7. Opcions de mapatge NFS Per començar, podem fer servir una configuració simple: ```text Maproot User: root Maproot Group: root ``` Això facilita la primera prova d’escriptura des de la VM. Més endavant, si volem afinar seguretat, podem passar a un UID/GID específic per al servei PeerTube. ## 8. Activar el servei NFS al TrueNAS Si el servei NFS no està actiu, l’activem: ```text System Settings → Services → NFS → Start Automatically System Settings → Services → NFS → Start ``` L’estat esperat és: ```text NFS: RUNNING ``` ## 9. Preparació de la VM Ubuntu Entrem a la VM PeerTube: ```bash xab@host-xab:~$ ssh peertube-vm ``` Passem a root: ```bash xab@peertube-vm:~$ sudo -i ``` Actualitzem índexs de paquets: ```bash root@peertube-vm:~# apt update ``` Instal·lem el client NFS: ```bash root@peertube-vm:~# apt install -y nfs-common ``` ## 10. Crear el punt de muntatge a la VM Creem el directori local on muntarem el recurs del TrueNAS: ```bash root@peertube-vm:~# mkdir -p /mnt/truenas-peertube ``` ## 11. Prova de muntatge manual Provem el muntatge NFS manualment: ```bash root@peertube-vm:~# mount -t nfs4 192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube ``` ## 12. Comprovar que s’ha muntat Comprovem amb `df`: ```bash root@peertube-vm:~# df -h | grep truenas ``` També podem veure el contingut: ```bash root@peertube-vm:~# ls -lna /mnt/truenas-peertube ``` I el directori de dades: ```bash root@peertube-vm:~# ls -lna /mnt/truenas-peertube/data ``` ## 13. Prova d’escriptura des de la VM Creem un fitxer de prova des de la VM Ubuntu: ```bash root@peertube-vm:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt ``` Comprovem que existeix: ```bash root@peertube-vm:~# ls -lna /mnt/truenas-peertube ``` També podem fer una prova dins la carpeta `data`: ```bash root@peertube-vm:~# touch /mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt ``` Comprovem: ```bash root@peertube-vm:~# ls -lna /mnt/truenas-peertube/data ``` ## 14. Comprovació des del TrueNAS Al TrueNAS haurien d’aparèixer els fitxers creats des de la VM: ```bash root@truenas:~# ls -lna /mnt/AV/VM/peertube ``` ```bash root@truenas:~# ls -lna /mnt/AV/VM/peertube/data ``` Resultat esperat: ```text prova-escriptura-des-de-peertube-vm.txt prova-data-des-de-peertube-vm.txt ``` ## 15. Si el muntatge dona error Si apareix un error com: ```text mount.nfs: access denied by server while mounting ``` cal revisar a TrueNAS: ```text Allowed hosts Path exportat Servei NFS actiu Permisos del dataset Maproot User / Group ``` Si apareix un error de xarxa, comprovem connectivitat: ```bash root@peertube-vm:~# ping -c 4 192.168.100.101 ``` I comprovem si el port NFS respon: ```bash root@peertube-vm:~# nc -vz 192.168.100.101 2049 ``` Si no tenim `nc`, l’instal·lem: ```bash root@peertube-vm:~# apt install -y netcat-openbsd ``` ## 16. Muntatge persistent amb /etc/fstab Si la prova manual funciona, fem el muntatge persistent. Editem `/etc/fstab`: ```bash root@peertube-vm:~# nano /etc/fstab ``` Afegim aquesta línia al final: ```fstab 192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube nfs4 defaults,_netdev,nofail,x-systemd.automount 0 0 ``` ## 17. Provar el muntatge persistent Primer desmuntem: ```bash root@peertube-vm:~# umount /mnt/truenas-peertube ``` Recarreguem systemd: ```bash root@peertube-vm:~# systemctl daemon-reload ``` Provem `fstab`: ```bash root@peertube-vm:~# mount -a ``` Comprovem: ```bash root@peertube-vm:~# df -h | grep truenas ``` I forcem accés al directori: ```bash root@peertube-vm:~# ls -lna /mnt/truenas-peertube ``` ## 18. Reinici de prova Quan el muntatge persistent funcioni, podem reiniciar la VM: ```bash root@peertube-vm:~# reboot ``` Després tornem a entrar: ```bash xab@host-xab:~$ ssh peertube-vm ``` Passem a root: ```bash xab@peertube-vm:~$ sudo -i ``` Comprovem que el muntatge continua funcionant, si no li fem un ls o qualsevol acció d'accés el df no el veu, és uncomportament normal. ```bash root@peertube-vm:~# ls -lna /mnt/truenas-peertube root@peertube-vm:~# df -h | grep truenas ``` ```bash ``` ## 19. Decisió documentada El directori del TrueNAS: ```text /mnt/AV/VM/peertube ``` queda muntat dins la VM Ubuntu com: ```text /mnt/truenas-peertube ``` Aquest muntatge serà la base per externalitzar la DATA gran de PeerTube. ## 20. Estat esperat al final d’aquesta fase ```text TrueNAS: /mnt/AV/VM/peertube /mnt/AV/VM/peertube/data VM Ubuntu: /mnt/truenas-peertube /mnt/truenas-peertube/data NFS: muntatge funcional escriptura validada entrada persistent a /etc/fstab PAUSA: ERROR EN ELS PERMISOS; REVISIÓ A TRUENAS DEL NFS # Diagnosi NFS: muntatge correcte però sense permís d’escriptura ## Situació La VM PeerTube pot muntar correctament el recurs NFS del TrueNAS: ```bash root@peer-tube:~# mount -t nfs4 192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube ``` La comprovació mostra que el muntatge és correcte: ```bash root@peer-tube:~# df -h | grep truenas ``` Resultat: ```text 192.168.100.101:/mnt/AV/VM/peertube 27G 0 27G 0% /mnt/truenas-peertube ``` També hi ha connectivitat IP correcta amb el TrueNAS: ```bash root@peer-tube:~# ping -c 4 192.168.100.101 ``` Resultat: ```text 64 bytes from 192.168.100.101 ``` ## Problema Tot i que el recurs NFS està muntat, no es pot escriure: ```bash root@peer-tube:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt ``` Error: ```text touch: cannot touch '/mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt': Permission denied ``` També falla dins de `data`: ```bash root@peer-tube:~# touch /mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt ``` Error: ```text touch: cannot touch '/mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt': Permission denied ``` ## Diagnosi El muntatge NFS funciona. El problema no és de xarxa ni de ruta exportada. El problema és de permisos NFS. La pista important és aquesta: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube ``` Resultat: ```text drwxrwxr-x 3 0 0 3 de juny 6 05:02 . drwxrwxr-x 11 0 0 11 de juny 6 05:07 data ``` Els directoris són propietat de: ```text UID: 0 GID: 0 ``` És a dir: ```text root:root ``` Però el `root` de la VM no pot escriure. Això indica que el TrueNAS està aplicant una política de NFS tipus: ```text root squash ``` És a dir: el `root` del client NFS no és acceptat com a `root` real al servidor TrueNAS. ## Explicació En NFS, el servidor pot decidir què fa amb les connexions que venen com a `root`. Per seguretat, sovint el `root` del client es mapeja a un usuari anònim, com ara: ```text nobody nogroup ``` Això evita que qualsevol màquina client amb accés NFS pugui escriure com a root al NAS. Per això passa això: ```text La VM munta bé el recurs. La VM veu els fitxers. Però root no pot escriure. ``` ## Missatges de nfs-common Els missatges que han sortit en instal·lar `nfs-common` són normals. Per exemple: ```text Adding system user `statd' nfs-idmapd.service is a disabled or a static unit rpc-statd.service is a disabled or a static unit ``` Això no és l’error. El paquet s’ha instal·lat correctament. El problema real és el mapatge de permisos al servidor NFS del TrueNAS. ## Solució ràpida per validar el laboratori A la GUI del TrueNAS, revisem l’export NFS: ```text Shares → Unix Shares (NFS) → export /mnt/AV/VM/peertube ``` Cal deixar una configuració semblant a: ```text Path: /mnt/AV/VM/peertube Allowed hosts: 192.168.100.111 Maproot User: root Maproot Group: root ``` Això permet que el `root` de la VM sigui tractat com a `root` sobre aquest export NFS. ## Opció recomanada ara mateix Per avançar en el desplegament i validar el muntatge: ```text Maproot User: root Maproot Group: root ``` Després guardem els canvis i reiniciem o recarreguem el servei NFS si cal. A TrueNAS: ```text System Settings → Services → NFS → Restart ``` ## Prova després de canviar Maproot A la VM PeerTube, desmuntem i tornem a muntar: ```bash root@peer-tube:~# umount /mnt/truenas-peertube ``` ```bash root@peer-tube:~# mount -t nfs4 192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube ``` Provem escriptura: ```bash root@peer-tube:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt ``` ```bash root@peer-tube:~# touch /mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt ``` Comprovem: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube ``` ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube/data ``` ## Si encara falla Si encara falla, fem una prova més oberta només per diagnosticar. Al TrueNAS: ```bash root@truenas:~# chmod -R 777 /mnt/AV/VM/peertube ``` Després, a la VM: ```bash root@peer-tube:~# touch /mnt/truenas-peertube/prova-777.txt ``` Si amb `777` funciona, queda confirmat que el problema era permisos Unix. Si amb `777` tampoc funciona, el problema és de configuració NFS, no només de permisos de fitxer. Després de la prova, no deixarem necessàriament `777`; només és diagnòstic. ## Alternativa més fina Més endavant, quan PeerTube estigui funcionant, podem veure quin UID/GID fa servir el contenidor per escriure dins de `/data`. Per exemple: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube id ``` I després fer que el dataset del TrueNAS sigui propietat d’aquell UID/GID. Però ara encara no tenim el contenidor en marxa. Per això, per arrencar el desplegament, la via ràpida és: ```text Maproot User: root Maproot Group: root ``` ## Decisió provisional Per aquesta fase del laboratori fem: ```text NFS restringit només a la VM 192.168.100.111 Maproot root:root Permisos 775 o 777 temporal si cal diagnosticar ``` Això ens permet validar: ```text VM Ubuntu → NFS → TrueNAS ``` ## Estat actual ```text Muntatge NFS: correcte Connectivitat: correcta Lectura: correcta Escriptura: falla Causa probable: root squash / mapatge NFS del TrueNAS Acció: revisar Maproot User i Maproot Group a l’export NFS ``` NOTA: DF NO POT ACCCEDIR SENSE LS PREVI;;;; # Nota sobre NFS amb `x-systemd.automount` ## Comportament observat Hem configurat el muntatge NFS del TrueNAS dins de la VM Ubuntu mitjançant `/etc/fstab`. La línia utilitzada inclou l’opció: ```fstab x-systemd.automount ``` Això fa que systemd prepari un punt d’automuntatge, però no necessàriament munta el recurs NFS immediatament durant l’arrencada. ## Conseqüència pràctica Després de reiniciar la VM, aquesta comprovació pot no mostrar res: ```bash root@peer-tube:~# df -h | grep truenas ``` Això no vol dir necessàriament que el muntatge estigui malament. Vol dir que el recurs encara no s’ha activat perquè ningú ha accedit al punt de muntatge. ## Com forçar l’automuntatge Primer cal accedir al directori muntat: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube ``` Aquest `ls` força systemd a activar el muntatge NFS. Després ja podem comprovar-lo amb: ```bash root@peer-tube:~# df -h | grep truenas ``` Ara sí que hauria d’aparèixer el recurs muntat: ```text 192.168.100.101:/mnt/AV/VM/peertube ... /mnt/truenas-peertube ``` ## Comprovació completa recomanada després d’un reinici Després de reiniciar la VM, fem: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube ``` ```bash root@peer-tube:~# df -h | grep truenas ``` ```bash root@peer-tube:~# touch /mnt/truenas-peertube/prova-post-reboot.txt ``` ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube ``` ## Decisió documentada Mantenim l’opció: ```fstab x-systemd.automount ``` perquè és adequada per a un muntatge NFS cap al TrueNAS. Aquesta opció evita que la VM quedi bloquejada durant l’arrencada si el TrueNAS encara no està disponible. Només cal recordar que, després d’un reinici, el muntatge pot no aparèixer a `df -h` fins que accedim primer al directori amb una ordre com: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube ``` ``` ## 21. Següent fase Quan el muntatge NFS estigui validat, passarem a: ```text Instal·lació de Docker Engine Instal·lació de Docker Compose Plugin Descàrrega dels fitxers oficials de PeerTube Preparació de /opt/peertube Separació de volums locals i volums sobre TrueNAS ``` # Desplegament de PeerTube: fase 2 ## 1. Objectiu de la fase Ara que ja tenim validat el muntatge NFS contra el TrueNAS, preparem la VM Ubuntu perquè pugui executar PeerTube amb Docker. En aquesta fase farem: ```text 1. Instal·lar dependències bàsiques 2. Afegir el repositori oficial de Docker 3. Instal·lar Docker Engine 4. Instal·lar Docker Compose Plugin 5. Activar Docker a l’arrencada 6. Fer una prova de funcionament ``` ## 2. Entrar a la VM PeerTube Des de l’ordinador local: ```bash xab@host-xab:~$ ssh peertube-vm ``` Passem a root: ```bash xab@peer-tube:~$ sudo -i ``` El prompt esperat és: ```bash root@peer-tube:~# ``` ## 3. Actualitzar el sistema Actualitzem els índexs de paquets: ```bash root@peer-tube:~# apt update ``` Actualitzem el sistema: ```bash root@peer-tube:~# apt upgrade -y ``` ## 4. Instal·lar dependències bàsiques Instal·lem paquets necessaris per afegir repositoris HTTPS i treballar amb claus GPG: ```bash root@peer-tube:~# apt install -y ca-certificates curl gnupg git nano vim htop nfs-common ufw ``` ## 5. Preparar el directori de claus APT Creem el directori per a claus de repositoris externs: ```bash root@peer-tube:~# install -m 0755 -d /etc/apt/keyrings ``` ## 6. Afegir la clau oficial de Docker Descarreguem la clau GPG oficial de Docker: ```bash root@peer-tube:~# curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc ``` Assignem permisos de lectura: ```bash root@peer-tube:~# chmod a+r /etc/apt/keyrings/docker.asc ``` ## 7. Afegir el repositori oficial de Docker Creem el fitxer del repositori Docker: ```bash root@peer-tube:~# tee /etc/apt/sources.list.d/docker.sources < docker-compose.yml ``` Descarreguem el fitxer `.env` oficial: ```bash root@peer-tube:/opt/peertube# curl https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/.env > .env ``` Comprovem: ```bash root@peer-tube:/opt/peertube# ls -lna ``` Resultat esperat: ```text root@peer-tube:/opt/peertube# ls -lna total 20 drwxr-xr-x 2 0 0 4096 de juny 6 06:17 . drwxr-xr-x 4 0 0 4096 de juny 6 06:14 .. -rw-r--r-- 1 0 0 3613 de juny 6 06:14 docker-compose.yml -rw-r--r-- 1 0 0 6199 de juny 6 06:17 .env ``` ## 6. Crear els directoris locals de Docker Creem l’estructura base de volums: ```bash root@peer-tube:/opt/peertube# mkdir -p docker-volume ``` Creem els volums que volem mantenir locals dins de la VM: ```bash root@peer-tube:/opt/peertube# mkdir -p docker-volume/db root@peer-tube:/opt/peertube# mkdir -p docker-volume/redis root@peer-tube:/opt/peertube# mkdir -p docker-volume/config root@peer-tube:/opt/peertube# mkdir -p docker-volume/opendkim/keys ``` ## 7. Enllaçar la DATA gran cap al TrueNAS No volem que el directori `docker-volume/data` sigui local. Volem que apunti al muntatge NFS: ```text /mnt/truenas-peertube/data ``` Creem l’enllaç simbòlic: ```bash root@peer-tube:/opt/peertube# ln -s /mnt/truenas-peertube/data docker-volume/data ``` ## 8. Comprovar l’estructura resultant Comprovem el directori `docker-volume`: ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume ``` Resultat esperat: ```text drwxr-xr-x db drwxr-xr-x redis drwxr-xr-x config drwxr-xr-x opendkim lrwxrwxrwx data -> /mnt/truenas-peertube/data ``` Comprovem que l’enllaç funciona: ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume/data ``` Això hauria de mostrar el contingut de: ```text /mnt/truenas-peertube/data ``` ## 9. Prova d’escriptura des del camí final Ara provem escriptura exactament pel camí que veurà Docker Compose: ```bash root@peer-tube:/opt/peertube# touch docker-volume/data/prova-des-de-ruta-final-docker-volume.txt ``` Comprovem: ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume/data ``` També podem comprovar-ho des del camí NFS real: ```bash root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube/data ``` ## 10. Separació real de dades Amb aquesta estructura, quan PeerTube escrigui a: ```text /data ``` dins del contenidor, realment escriurà a: ```text /opt/peertube/docker-volume/data ``` I aquest camí és un enllaç cap a: ```text /mnt/truenas-peertube/data ``` Per tant, físicament les dades grans acabaran al TrueNAS. ## 11. Què queda local a la VM A la VM queden locals: ```text /opt/peertube/docker-volume/db /opt/peertube/docker-volume/redis /opt/peertube/docker-volume/config /opt/peertube/docker-volume/opendkim /opt/peertube/docker-compose.yml /opt/peertube/.env ``` Això inclou: ```text PostgreSQL Redis configuració PeerTube OpenDKIM fitxers del desplegament ``` ## 12. Què queda al TrueNAS Al TrueNAS queda: ```text /mnt/AV/VM/peertube/data ``` Que la VM veu com: ```text /mnt/truenas-peertube/data ``` I Docker Compose veu com: ```text /opt/peertube/docker-volume/data ``` Aquest directori contindrà: ```text vídeos originals vídeos transcodificats HLS / streaming playlists thumbnails previews imports captions storyboards tmp ``` ## 13. Esquema final de camins ```text Contenidor PeerTube: /data VM Ubuntu: /opt/peertube/docker-volume/data Enllaç simbòlic: /opt/peertube/docker-volume/data -> /mnt/truenas-peertube/data TrueNAS: /mnt/AV/VM/peertube/data ``` ## 14. Comprovació general Abans d’editar el `docker-compose.yml`, comprovem: ```bash root@peer-tube:/opt/peertube# pwd ``` Resultat esperat: ```text /opt/peertube ``` Comprovem fitxers principals: ```bash root@peer-tube:/opt/peertube# ls -lna ``` Comprovem volums: ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume ``` Comprovem muntatge: ```bash root@peer-tube:/opt/peertube# df -h | grep truenas ``` Comprovem escriptura final: ```bash root@peer-tube:/opt/peertube# touch docker-volume/data/prova-final.txt ``` ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume/data | grep prova-final ``` ## 15. Decisió documentada Fem servir `/opt/peertube` com a directori principal del desplegament. El volum `docker-volume/data` no és local: és un enllaç simbòlic cap al muntatge NFS del TrueNAS. Això permet mantenir locals les dades crítiques de gestió i base de dades, però externalitzar la DATA gran audiovisual. ## 16. Estat esperat al final d’aquesta fase ```text /opt/peertube/docker-compose.yml /opt/peertube/.env /opt/peertube/docker-volume/db /opt/peertube/docker-volume/redis /opt/peertube/docker-volume/config /opt/peertube/docker-volume/opendkim /opt/peertube/docker-volume/data -> /mnt/truenas-peertube/data ``` ## 17. Següent fase La següent fase serà editar: ```text docker-compose.yml .env ``` Per adaptar-los al nostre escenari: ```text sense webserver intern sense certbot intern sense webserver-reloader amb PeerTube publicant el port 9000 amb domini públic definit amb HTTPS declarat perquè el proxy extern farà TLS amb PostgreSQL i Redis locals amb /data apuntant al TrueNAS ``` # Desplegament de PeerTube: fase 4 ## 1. Objectiu de la fase En aquesta fase adaptem els fitxers oficials de PeerTube al nostre escenari. Tenim: ```text VM Ubuntu PeerTube IP: 192.168.100.111 TrueNAS IP: 192.168.100.101 Directori de desplegament /opt/peertube DATA gran /opt/peertube/docker-volume/data -> /mnt/truenas-peertube/data Proxy invers extern CT Apache ``` No volem que PeerTube aixequi el seu propi Nginx ni Certbot, perquè això ho farà el CT Apache extern. Per tant, eliminem o comentem aquests serveis del `docker-compose.yml`: ```text webserver certbot webserver-reloader ``` I fem que el servei `peertube` publiqui el port intern: ```text 9000/tcp ``` ## 2. Fer còpies de seguretat dels fitxers originals Entrem al directori del desplegament: ```bash root@peer-tube:~# cd /opt/peertube ``` Fem còpia del `docker-compose.yml` original: ```bash root@peer-tube:/opt/peertube# cp docker-compose.yml docker-compose.yml.original ``` Fem còpia del `.env` original: ```bash root@peer-tube:/opt/peertube# cp .env .env.original ``` Comprovem: ```bash root@peer-tube:/opt/peertube# ls -lna ``` Resultat esperat: ```text .env .env.original docker-compose.yml docker-compose.yml.original docker-volume ``` ## 3. Generar contrasenya de PostgreSQL Generem una contrasenya llarga per PostgreSQL: ```bash root@peer-tube:/opt/peertube# openssl rand -base64 32 ``` Guardem el resultat per posar-lo al `.env`. Exemple de valor: ```text CONTRASENYA_LLARGA_POSTGRES Nv47Om0bTtuSdEmCVyb10oGk2YDo9lcgkxj5Z+RzeIM= ``` ## 4. Generar secret de PeerTube Generem el secret de PeerTube: ```bash root@peer-tube:/opt/peertube# openssl rand -hex 32 ``` Guardem el resultat per posar-lo al `.env`. Exemple de valor: ```text SECRET_LLARG_PEERTUBE 7938b6b369366e32647c9421f34840b23bd06b23a7bde08ce36151b70107daf6 ``` ## 5. Editar el fitxer .env Obrim el fitxer `.env`: ```bash root@peer-tube:/opt/peertube# nano .env ``` Hem de substituir els valors de plantilla pel nostre escenari. Els valors principals són: ```env POSTGRES_USER=peertube POSTGRES_PASSWORD=CONTRASENYA_LLARGA_POSTGRES POSTGRES_DB=peertube_prod PEERTUBE_WEBSERVER_HOSTNAME=DOMINI_TRIAT PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true PEERTUBE_ADMIN_EMAIL=CORREU_ADMIN PEERTUBE_SECRET=SECRET_LLARG_PEERTUBE PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "192.168.100.0/24"] ``` ## 6. Notes sobre el domini El domini s’ha d’escriure sense protocol. Correcte: ```text video.exemple.cat ``` Incorrecte: ```text https://video.exemple.cat ``` Per tant: ```env PEERTUBE_WEBSERVER_HOSTNAME=video.exemple.cat ``` ## 7. Notes sobre HTTPS Encara que PeerTube internament escolti per HTTP al port `9000`, de cara a l’exterior el servei serà HTTPS perquè el CT Apache farà el TLS. Per això posem: ```env PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true ``` Això fa que PeerTube generi URLs públiques correctes amb: ```text https://DOMINI_TRIAT ``` ## 8. Notes sobre TRUST_PROXY Com que PeerTube estarà darrere d’un proxy invers Apache, cal confiar en el proxy. Posem: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "192.168.100.0/24"] ``` Això cobreix el cas en què el CT Apache i la VM PeerTube estiguin dins la xarxa: ```text 192.168.100.0/24 ``` Si el CT Apache té una IP concreta i volem ser més estrictes, podríem posar només aquella IP. Per exemple: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "192.168.100.50"] ``` ## 9. Exemple de bloc .env adaptat Aquest és un exemple conceptual. Cal substituir `DOMINI_TRIAT`, `CORREU_ADMIN`, `CONTRASENYA_LLARGA_POSTGRES` i `SECRET_LLARG_PEERTUBE`. ```env POSTGRES_USER=peertube POSTGRES_PASSWORD=CONTRASENYA_LLARGA_POSTGRES POSTGRES_DB=peertube_prod PEERTUBE_WEBSERVER_HOSTNAME=DOMINI_TRIAT PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true PEERTUBE_ADMIN_EMAIL=CORREU_ADMIN PEERTUBE_SECRET=SECRET_LLARG_PEERTUBE PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "192.168.100.0/24"] ``` ## 10. Editar docker-compose.yml Obrim el fitxer: ```bash root@peer-tube:/opt/peertube# nano docker-compose.yml ``` Hem de modificar tres coses: ```text 1. Desactivar el servei webserver 2. Desactivar el servei certbot 3. Desactivar el servei webserver-reloader 4. Activar el port 9000 al servei peertube ``` # docker-compose.yml adaptat per al desplegament PeerTube amb proxy Apache extern ## Fitxer modificat Aquest fitxer parteix del `docker-compose.yml` oficial de PeerTube, però s’ha adaptat al nostre escenari. En aquest desplegament **no fem servir el webserver Nginx oficial de PeerTube**, perquè el proxy invers i el TLS els gestionarà un altre CT amb Apache. Per tant, deixem comentats els serveis: ```text webserver certbot webserver-reloader ``` El servei `peertube` exposarà directament el port intern `9000` a la VM Ubuntu: ```text 192.168.100.111:9000 ``` Aquest port serà consumit pel CT Apache Reverse Proxy. ## Fitxer `docker-compose.yml` ```yaml services: ########################################################################### # WEBSERVER OFICIAL DE PEERTUBE ########################################################################### # # NO EL FEM SERVIR. # # Motiu: # En aquest projecte el proxy invers i HTTPS els gestionarà un altre CT # amb Apache. Per tant, no necessitem el contenidor webserver oficial # basat en Nginx. # # Si deixéssim aquest servei actiu, intentaria ocupar els ports 80 i 443 # dins la VM PeerTube, cosa que no volem. # ########################################################################### # webserver: # image: chocobozzz/peertube-webserver:latest # env_file: # - .env # ports: # - "80:80" # - "443:443" # volumes: # - type: bind # source: ./docker-volume/nginx/peertube # target: /etc/nginx/conf.d/peertube.template # - assets:/var/www/peertube/peertube-latest/client/dist:ro # - ./docker-volume/data:/var/www/peertube/storage # - certbot-www:/var/www/certbot # - ./docker-volume/certbot/conf:/etc/letsencrypt # - ./docker-volume/nginx-logs:/var/log/nginx # depends_on: # - peertube # restart: "always" ########################################################################### # CERTBOT OFICIAL DEL COMPOSE ########################################################################### # # NO EL FEM SERVIR. # # Motiu: # Els certificats TLS no es gestionaran des d’aquesta VM PeerTube. # Els gestionarà el CT Apache Reverse Proxy. # ########################################################################### # certbot: # container_name: certbot # image: certbot/certbot # volumes: # - ./docker-volume/certbot/conf:/etc/letsencrypt # - certbot-www:/var/www/certbot # restart: unless-stopped # entrypoint: /bin/sh -c "trap exit TERM; while :; do certbot renew --webroot -w /var/www/certbot; sleep 12h & wait $${!}; done;" # depends_on: # - webserver ########################################################################### # WEBSERVER RELOADER ########################################################################### # # NO EL FEM SERVIR. # # Motiu: # Aquest servei només té sentit si fem servir el webserver oficial. # Com que el webserver oficial està desactivat, aquest servei també queda # desactivat. # ########################################################################### # webserver-reloader: # image: alpine:latest # command: > # sh -c "trap exit TERM; # while :; do # sleep 21600 & wait $$!; # echo 'Sending reload signal to webserver...'; # kill -HUP 1; # done" # pid: "service:webserver" # depends_on: # - webserver # restart: "always" ########################################################################### # PEERTUBE ########################################################################### # # Aquest és el servei principal de l’aplicació. # # Exposem el port 9000 perquè el CT Apache extern pugui fer proxy cap a: # # http://192.168.100.111:9000 # # El port 1935 queda comentat de moment. Només caldrà activar-lo si volem # funcionalitat de directes RTMP. # ########################################################################### peertube: image: chocobozzz/peertube:production # Es manté la IP estàtica interna del contenidor perquè és la configuració # prevista pel compose oficial. networks: default: ipv4_address: 172.18.0.42 ipv6_address: fdab:e4b3:21a2:ef1b::42 env_file: - .env ports: # Port HTTP intern de PeerTube exposat a la VM. # El CT Apache farà proxy cap a aquest port. - "9000:9000" # Port RTMP per a directes. # De moment el deixem desactivat. # - "1935:1935" volumes: # Aquesta línia només calia per compartir assets amb el webserver oficial. # Com que no fem servir el webserver oficial, queda comentada. # - assets:/app/client/dist # DATA gran de PeerTube. # En el nostre cas aquest directori és un enllaç simbòlic cap al TrueNAS: # # ./docker-volume/data -> /mnt/truenas-peertube/data # - ./docker-volume/data:/data # Configuració interna de PeerTube. # Aquesta queda local dins la VM. - ./docker-volume/config:/config depends_on: - postgres - redis - postfix restart: "always" ########################################################################### # POSTGRESQL ########################################################################### # # Base de dades de PeerTube. # # IMPORTANT: # Aquesta part queda local dins la VM Ubuntu. # No la posem al TrueNAS per NFS. # ########################################################################### postgres: image: postgres:17-alpine env_file: - .env volumes: - ./docker-volume/db:/var/lib/postgresql/data restart: "always" ########################################################################### # REDIS ########################################################################### # # Redis queda local dins la VM Ubuntu. # ########################################################################### redis: image: redis:8-alpine volumes: - ./docker-volume/redis:/data restart: "always" ########################################################################### # POSTFIX ########################################################################### # # Servei de correu del compose oficial. # # El mantenim perquè PeerTube pot necessitar enviar correus. # La configuració fina dependrà després de l’SMTP que vulguem usar. # ########################################################################### postfix: image: mwader/postfix-relay env_file: - .env volumes: - ./docker-volume/opendkim/keys:/etc/opendkim/keys restart: "always" ########################################################################### # XARXA DOCKER ########################################################################### # # Mantenim la xarxa definida pel compose oficial. # ########################################################################### networks: default: enable_ipv6: true ipam: driver: default config: - subnet: 172.18.0.0/16 - subnet: fdab:e4b3:21a2:ef1b::/64 ########################################################################### # VOLUMS DOCKER ########################################################################### # # El volum assets queda comentat perquè només era necessari per al webserver # oficial. # # El volum certbot-www també queda comentat perquè no fem servir certbot dins # aquesta VM. # ########################################################################### # volumes: # assets: # certbot-www: ``` ## Aplicació del canvi Podem substituir el fitxer actual així: ```bash root@peer-tube:/opt/peertube# cp docker-compose.yml docker-compose.yml.original ``` ```bash root@peer-tube:/opt/peertube# nano docker-compose.yml ``` Enganxem el contingut modificat i desem. ## Validació del fitxer Després comprovem que el YAML és correcte: ```bash root@peer-tube:/opt/peertube# docker compose config ``` Si no hi ha errors, mirem quins serveis detecta: ```bash root@peer-tube:/opt/peertube# docker compose config --services ``` El resultat esperat és: ```text peertube postgres redis postfix ``` No han d’aparèixer: ```text webserver certbot webserver-reloader ``` ## Decisió documentada El `docker-compose.yml` queda adaptat per funcionar amb un proxy invers extern. PeerTube queda exposat internament a: ```text http://192.168.100.111:9000 ``` I el CT Apache serà qui publicarà el servei amb HTTPS cap a internet. ## Separació de dades ```text Local VM Ubuntu: ./docker-volume/db ./docker-volume/redis ./docker-volume/config ./docker-volume/opendkim TrueNAS: ./docker-volume/data -> /mnt/truenas-peertube/data ``` ## 18. Validar sintaxi del compose Després de modificar el fitxer, validem la configuració: ```bash root@peer-tube:/opt/peertube# docker compose config ``` Si hi ha errors de YAML, aquesta ordre els mostrarà. Si tot és correcte, imprimirà la configuració final expandida. ## 19. Comprovar que el webserver ja no hi és Podem mirar quins serveis detecta Compose: ```bash root@peer-tube:/opt/peertube# docker compose config --services ``` Resultat esperat aproximat: ```text postgres redis postfix peertube ``` No haurien d’aparèixer: ```text webserver certbot webserver-reloader ``` ## 20. Primera descàrrega d’imatges Quan la configuració sigui vàlida, descarreguem imatges: ```bash root@peer-tube:/opt/peertube# docker compose pull ``` Això descarregarà: ```text PeerTube PostgreSQL Redis Postfix ``` ## 21. Primera arrencada Arrenquem en segon pla: ```bash root@peer-tube:/opt/peertube# docker compose up -d ``` ## 22. Veure estat dels contenidors ```bash root@peer-tube:/opt/peertube# docker compose ps ``` Resultat esperat: ```text postgres running redis running postfix running peertube running ``` ## 23. Veure logs de PeerTube ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` En aquesta primera arrencada poden sortir missatges d’inicialització de base de dades i configuració. ERRORS PRIMER UP falten unes dobles cometes per separat array de proxy # Correcció de `PEERTUBE_TRUST_PROXY` ## Error detectat Després de la primera arrencada amb: ```bash root@peer-tube:/opt/peertube# docker compose up -d ``` els logs de PeerTube mostren aquest error: ```text TypeError: invalid range on address: 172.18.0.0/16, 192.168.100.104 ``` ## Diagnosi El problema és a la variable: ```env PEERTUBE_TRUST_PROXY ``` PeerTube està rebent aquesta part: ```text 172.18.0.0/16, 192.168.100.104 ``` com si fos **una única adreça o rang**, i això no és vàlid. El que volem és que ho interpreti com una llista de proxys o xarxes de confiança. ## Valor incorrecte probable Al `.env` probablement hi ha alguna cosa semblant a: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16, 192.168.100.104"] ``` El problema és que aquesta part està dins les mateixes cometes: ```text "172.18.0.0/16, 192.168.100.104" ``` Això ho converteix en una sola entrada. ## Valor correcte Cal posar cada element separat dins l’array: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` ## Què representa cada entrada ```text 127.0.0.1 localhost loopback rangs loopback reconeguts per Express/Node 172.18.0.0/16 xarxa interna Docker definida al docker-compose.yml 192.168.100.104 IP del CT Apache Reverse Proxy ``` ## Important La IP `192.168.100.104` ha de ser la IP real del CT Apache que farà de proxy invers. Si el CT Apache té una altra IP, cal posar aquella. Per exemple, si el CT Apache fos: ```text 192.168.100.50 ``` la línia hauria de ser: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.50"] ``` ## Correcció del fitxer .env Editem el fitxer: ```bash root@peer-tube:/opt/peertube# nano .env ``` Busquem: ```env PEERTUBE_TRUST_PROXY= ``` I deixem la línia així: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` ## Aturar i recrear contenidors Després de canviar el `.env`, cal recrear el contenidor perquè agafi la nova variable. Primer aturem: ```bash root@peer-tube:/opt/peertube# docker compose down ``` Després tornem a aixecar: ```bash root@peer-tube:/opt/peertube# docker compose up -d ``` ## Comprovar estat ```bash root@peer-tube:/opt/peertube# docker compose ps ``` ## Consultar logs ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` Ja no hauria d’aparèixer: ```text invalid range on address ``` ## Comprovar la variable dins del contenidor Podem comprovar què ha rebut realment el contenidor: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube printenv | grep PEERTUBE_TRUST_PROXY ``` El resultat esperat és: ```text PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` ## Validar el compose També podem validar: ```bash root@peer-tube:/opt/peertube# docker compose config | grep PEERTUBE_TRUST_PROXY ``` ## Decisió documentada El CT Apache Reverse Proxy queda declarat com a proxy de confiança de PeerTube. Això és necessari perquè PeerTube interpreti correctament capçaleres com: ```text X-Forwarded-For X-Forwarded-Proto Host ``` Sense aquesta configuració, PeerTube pot interpretar malament: ```text IP real del client protocol públic HTTPS domini públic ``` ## Resum Valor corregit: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` Accions: ```bash root@peer-tube:/opt/peertube# docker compose down root@peer-tube:/opt/peertube# docker compose up -d root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` ## 24. Comprovar que escolta el port 9000 ```bash root@peer-tube:/opt/peertube# ss -lntp | grep 9000 ``` Resultat esperat: ```text LISTEN ... :9000 ``` ## 25. Prova HTTP local Des de la mateixa VM: ```bash root@peer-tube:/opt/peertube# curl -I http://127.0.0.1:9000 ``` Des del Proxmox: ```bash root@base:~# curl -I http://192.168.100.111:9000 ``` Des del CT Apache també hauria de respondre: ```bash root@apache-proxy:~# curl -I http://192.168.100.111:9000 ``` ## 26. Obtenir la contrasenya inicial de root Un cop PeerTube hagi arrencat, podem buscar la contrasenya inicial de l’usuari `root` als logs: ```bash root@peer-tube:/opt/peertube# docker compose logs peertube | grep -A1 root ``` Si cal reiniciar-la manualment: ```bash root@peer-tube:/opt/peertube# docker compose exec -u peertube peertube npm run reset-password -- -u root ``` ## 27. Comprovar que la DATA escriu al TrueNAS Mentre PeerTube arrenca, comprovem que el directori `data` continua sent l’enllaç cap al TrueNAS: ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume ``` Resultat esperat: ```text data -> /mnt/truenas-peertube/data ``` Comprovem el muntatge: ```bash root@peer-tube:/opt/peertube# df -h | grep truenas ``` Si no surt, forcem l’automount: ```bash root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube ``` I tornem a provar: ```bash root@peer-tube:/opt/peertube# df -h | grep truenas ``` ## 28. Decisió documentada El desplegament de PeerTube queda adaptat així: ```text Serveis Docker actius: postgres redis postfix peertube Serveis Docker desactivats: webserver certbot webserver-reloader ``` El servei públic no l’exposa PeerTube directament. L’exposició pública es farà amb: ```text CT Apache Reverse Proxy → http://192.168.100.111:9000 ``` ## 29. Estat esperat al final d’aquesta fase ```text docker compose config → sense errors docker compose config --services → postgres → redis → postfix → peertube docker compose ps → contenidors running curl -I http://127.0.0.1:9000 → resposta HTTP curl -I http://192.168.100.111:9000 → resposta HTTP des del Proxmox o CT Apache ``` ## 30. Següent fase La següent fase serà configurar el CT Apache com a reverse proxy cap a: ```text http://192.168.100.111:9000 ``` I validar l’accés públic amb: ```text https://DOMINI_TRIAT ``` # Validació inicial de PeerTube ## Situació Després de corregir el valor de `PEERTUBE_TRUST_PROXY`, el contenidor de PeerTube s’aixeca correctament. La comprovació HTTP contra el port intern de la VM retorna resposta vàlida. ## Prova feta des de la VM i des del Proxmox ```bash root@base:~# curl -I http://192.168.100.111:9000 ``` Resultat: ```text HTTP/1.1 200 OK x-powered-by: PeerTube X-Frame-Options: DENY Tk: N Access-Control-Allow-Origin: * X-RateLimit-Limit: 500 X-RateLimit-Remaining: 499 Date: Sat, 06 Jun 2026 10:27:19 GMT X-RateLimit-Reset: 1780741650 Content-Type: text/html; charset=utf-8 Cache-Control: max-age=0, no-cache, must-revalidate Vary: Accept-Language Content-Length: 21165 ETag: W/"52ad-8Td+OFxxict6kAkUm1NvqAWynKU" Connection: keep-alive Keep-Alive: timeout=5 ``` ## Resultat de la prova La resposta és correcta: ```text HTTP/1.1 200 OK ``` I confirma que el servei que respon és PeerTube: ```text x-powered-by: PeerTube ``` ## Diagnosi PeerTube està funcionant internament a: ```text http://192.168.100.111:9000 ``` Això confirma que: ```text Docker funciona docker compose funciona PostgreSQL funciona Redis funciona PeerTube arrenca El port 9000 està exposat correctament La VM respon des de la xarxa interna ``` ## Correcció aplicada El problema anterior venia de la variable: ```env PEERTUBE_TRUST_PROXY ``` El valor havia de tenir cada element separat i amb les cometes correctes. Exemple correcte: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` El valor incorrecte feia que PeerTube interpretés més d’una adreça com si fos un únic rang. ## Estat actual del desplegament ```text VM PeerTube: IP: 192.168.100.111 Port intern: 9000 Estat: respon HTTP 200 OK TrueNAS: IP: 192.168.100.101 Muntatge NFS: funcional DATA gran: muntada a /mnt/truenas-peertube/data Docker: PeerTube: aixecat PostgreSQL: aixecat Redis: aixecat Postfix: aixecat Proxy Apache: pendent de configurar ``` ## Comprovacions útils ara Veure contenidors: ```bash root@peer-tube:/opt/peertube# docker compose ps ``` Veure logs de PeerTube: ```bash root@peer-tube:/opt/peertube# docker compose logs --tail=100 peertube ``` Comprovar que el muntatge TrueNAS continua actiu: ```bash root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube ``` ```bash root@peer-tube:/opt/peertube# df -h | grep truenas ``` Comprovar que `docker-volume/data` apunta al TrueNAS: ```bash root@peer-tube:/opt/peertube# ls -lna docker-volume ``` Resultat esperat: ```text data -> /mnt/truenas-peertube/data ``` ## Decisió documentada El backend PeerTube queda validat abans de configurar el proxy invers. Això és important perquè separa dos problemes diferents: ```text 1. PeerTube funciona internament 2. Apache publicarà PeerTube cap a fora ``` Ara ja sabem que el punt 1 està resolt. ## Següent fase El següent pas és configurar el CT Apache Reverse Proxy perquè publiqui: ```text https://DOMINI_TRIAT ``` cap al backend intern: ```text http://192.168.100.111:9000 ``` El virtualhost Apache haurà de gestionar: ```text TLS / certificat ProxyPass ProxyPassReverse capçaleres X-Forwarded-Proto capçaleres X-Forwarded-For WebSocket si cal límit de mida de pujada ``` PROBLEMA AMB CERTBOT I CADDY # Diagnosi Apache / Certbot: port 80 i 443 ocupats ## 1. Situació observada S’ha creat el VirtualHost d’Apache per PeerTube, s’ha activat amb `a2ensite` i s’ha fet `reload`. Posteriorment, en executar Certbot, Apache falla amb: ```text Action 'graceful' failed ``` El log mostra: ```text (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down AH00015: Unable to open logs ``` També es veu: ```text AH00112: Warning: DocumentRoot [/home/rtd/public/m16] does not exist ``` ## 2. Estat actual dels ports Com a usuari normal s’ha executat: ```bash rtd@Vhost:~$ ss -ltnp | grep ':80' ``` I mostra: ```text LISTEN 0 4096 *:80 *:* ``` També: ```bash rtd@Vhost:~$ ss -ltnp | grep ':443' ``` I mostra: ```text LISTEN 0 4096 *:443 *:* ``` Això confirma que els ports 80 i 443 estan ocupats. Però com que l’ordre no s’ha executat com a root, no mostra quin procés els ocupa. ## 3. Primera comprovació important Cal executar `ss` com a root: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` O bé, si encara estem com a `rtd`: ```bash rtd@Vhost:~$ sudo ss -ltnp | grep -E ':80|:443' ``` El resultat hauria de mostrar el procés, per exemple: ```text users:(("apache2",pid=...,fd=...)) ``` o bé: ```text users:(("nginx",pid=...,fd=...)) ``` o bé: ```text users:(("docker-proxy",pid=...,fd=...)) ``` ## 4. Hipòtesi més probable Pel log, sembla que Apache estava funcionant, però durant el reload/start ha quedat en estat inconsistent. Això es veu aquí: ```text apache2.service: Killing process 1310773 (apache2) with signal SIGKILL. apache2.service: Killing process 1310775 (apache2) with signal SIGKILL. apache2.service: Failed with result 'exit-code'. ``` Després, quan systemd intenta tornar-lo a iniciar: ```text Address already in use ``` Això pot passar si han quedat processos Apache vius fora del control normal de systemd, o si un altre servei ha agafat el port. ## 5. Comprovar l’estat real d’Apache ```bash root@Vhost:~# systemctl status apache2 ``` També: ```bash root@Vhost:~# ps aux | grep apache2 ``` I: ```bash root@Vhost:~# apache2ctl -S ``` Aquesta última ordre mostra quins VirtualHosts veu Apache i pot ajudar a detectar configuracions duplicades o estranyes. ## 6. Comprovar sintaxi de configuració Abans de tocar Certbot, Apache ha de passar aquest test: ```bash root@Vhost:~# apache2ctl configtest ``` El resultat correcte és: ```text Syntax OK ``` Si surt qualsevol altre error, cal corregir-lo abans de tornar a executar Certbot. ## 7. Localitzar el DocumentRoot inexistent El warning és: ```text DocumentRoot [/home/rtd/public/m16] does not exist ``` Busquem quin VirtualHost el declara: ```bash root@Vhost:~# grep -R "/home/rtd/public/m16" /etc/apache2/sites-available /etc/apache2/sites-enabled ``` Si és un site antic que ja no fem servir, el desactivem: ```bash root@Vhost:~# a2dissite NOM_DEL_SITE.conf ``` Si encara el volem mantenir, creem el directori: ```bash root@Vhost:~# mkdir -p /home/rtd/public/m16 ``` I opcionalment un index mínim: ```bash root@Vhost:~# echo "OK m16" > /home/rtd/public/m16/index.html ``` Aquest warning no sembla el bloqueig principal, però convé deixar-lo net. ## 8. Si els ports 80/443 els ocupa Apache Si aquesta ordre: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` mostra que qui ocupa els ports és `apache2`, però `systemctl status apache2` diu que el servei està fallit, fem neteja controlada. Primer intentem aturar Apache: ```bash root@Vhost:~# systemctl stop apache2 ``` Comprovem si encara queda escoltant: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` Si encara apareixen processos `apache2`, els mirem: ```bash root@Vhost:~# ps aux | grep apache2 ``` I només si cal, matem processos Apache penjats: ```bash root@Vhost:~# pkill apache2 ``` Tornem a comprovar: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` Ara no hauria de sortir res ocupant 80/443. Després netegem l’estat de systemd: ```bash root@Vhost:~# systemctl reset-failed apache2 ``` Validem configuració: ```bash root@Vhost:~# apache2ctl configtest ``` I arrenquem Apache: ```bash root@Vhost:~# systemctl start apache2 ``` Comprovem: ```bash root@Vhost:~# systemctl status apache2 ``` I ports: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` Ara haurien de sortir ocupats per Apache, però amb el servei en estat correcte: ```text active (running) ``` ## 9. Si els ports els ocupa un altre servei Si `ss` mostra `nginx`: ```bash root@Vhost:~# systemctl status nginx ``` Si no el necessitem: ```bash root@Vhost:~# systemctl stop nginx ``` ```bash root@Vhost:~# systemctl disable nginx ``` Si mostra `docker-proxy`: ```bash root@Vhost:~# docker ps ``` Caldrà veure quin contenidor publica 80/443 i aturar-lo o canviar-li ports. ## 10. Tornar a provar Apache net Quan els ports estiguin sota control, fem: ```bash root@Vhost:~# apache2ctl configtest ``` ```bash root@Vhost:~# systemctl restart apache2 ``` ```bash root@Vhost:~# systemctl status apache2 ``` ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` ## 11. Provar el VirtualHost HTTP abans de Certbot Abans de tornar a Certbot, el VirtualHost HTTP ha de respondre. Des del mateix CT Apache: ```bash root@Vhost:~# curl -I http://DOMINI_TRIAT ``` També provem el backend PeerTube: ```bash root@Vhost:~# curl -I http://192.168.100.111:9000 ``` El backend PeerTube hauria de respondre: ```text HTTP/1.1 200 OK x-powered-by: PeerTube ``` ## 12. Tornar a executar Certbot Només quan Apache estigui en estat correcte: ```text apache2ctl configtest → Syntax OK systemctl status apache2 → active (running) curl http://DOMINI_TRIAT → respon ``` tornem a Certbot: ```bash root@Vhost:~# certbot --apache -d DOMINI_TRIAT ``` ## 13. Comandes immediates recomanades Ara mateix executaria aquest bloc: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' root@Vhost:~# systemctl status apache2 root@Vhost:~# ps aux | grep apache2 root@Vhost:~# apache2ctl configtest root@Vhost:~# apache2ctl -S ``` ## 14. Interpretació ràpida El punt clau és aquest: ```text El port 80 està ocupat, però Apache/systemd està en estat fallit. ``` Això s’ha de resoldre abans de Certbot. Certbot no podrà instal·lar ni modificar correctament el VirtualHost mentre Apache no pugui fer reload/restart netament. # Diagnosi: per què Caddy està ocupant els ports 80 i 443? ## 1. Situació Apache no pot arrencar perquè els ports 80 i 443 ja estan ocupats. La comprovació mostra: ```bash root@Vhost:~# ss -ltnp | grep ':80' ``` Resultat: ```text LISTEN 0 4096 *:80 *:* users:(("caddy",pid=1311928,fd=8)) ``` I també: ```bash root@Vhost:~# ss -ltnp | grep ':443' ``` Resultat: ```text LISTEN 0 4096 *:443 *:* users:(("caddy",pid=1311928,fd=6)) ``` Per tant, el procés que ocupa els ports públics és: ```text caddy ``` Ara cal saber: ```text qui ha arrencat Caddy si està habilitat al boot si depèn de systemd si l’ha iniciat algun script, timer o contenidor si forma part d’un servei antic del CT Vhost ``` ## 2. Veure l’estat del servei Caddy Primer mirem si Caddy està gestionat per systemd: ```bash root@Vhost:~# systemctl status caddy ``` Aquesta ordre ens dirà: ```text si el servei està actiu des de quan està actiu quin PID principal té quin fitxer de servei utilitza si està habilitat o no ``` Cal mirar especialment línies com: ```text Loaded: loaded (...; enabled; ...) Active: active (running) since ... Main PID: 1311928 (caddy) ``` Si diu: ```text enabled ``` vol dir que Caddy està configurat per arrencar automàticament amb la màquina. ## 3. Veure si Caddy està habilitat al boot ```bash root@Vhost:~# systemctl is-enabled caddy ``` Resultats possibles: ```text enabled ``` Vol dir que Caddy arrenca automàticament. ```text disabled ``` Vol dir que no hauria d’arrencar sol amb el boot, però algú l’ha pogut iniciar manualment. ```text static ``` Vol dir que no s’activa directament, però pot ser requerit per una altra unitat. ## 4. Veure qui és el pare del procés Caddy Comprovem l’arbre de processos: ```bash root@Vhost:~# ps -fp 1311928 ``` I també: ```bash root@Vhost:~# pstree -sp 1311928 ``` Resultat esperat si l’ha arrencat systemd: ```text systemd───caddy ``` Això indicaria que Caddy és un servei normal gestionat per systemd. Si sortís una altra cosa, per exemple un script o un procés Docker, caldria investigar aquell procés pare. ## 5. Veure la unitat systemd de Caddy ```bash root@Vhost:~# systemctl cat caddy ``` Això mostrarà el fitxer de servei, normalment alguna cosa com: ```text /etc/systemd/system/caddy.service ``` o: ```text /lib/systemd/system/caddy.service ``` Cal mirar sobretot: ```text ExecStart= ExecReload= User= Group= ``` Això ens dirà com s’està arrencant Caddy. ## 6. Veure quan s’ha arrencat Caddy Mirem el journal del servei: ```bash root@Vhost:~# journalctl -u caddy -n 100 --no-pager ``` Per veure només el boot actual: ```bash root@Vhost:~# journalctl -u caddy -b --no-pager ``` Això ens hauria de dir si Caddy ha arrencat durant l’arrencada del sistema. Busquem línies semblants a: ```text Started caddy.service - Caddy. ``` o: ```text systemd[1]: Starting caddy.service ``` ## 7. Comparar amb l’arrencada del sistema Mirem quan ha arrencat el CT o la màquina: ```bash root@Vhost:~# uptime -s ``` I comparem-ho amb: ```bash root@Vhost:~# systemctl status caddy ``` Si l’hora d’inici de Caddy coincideix amb l’arrencada del sistema, és gairebé segur que està habilitat al boot. ## 8. Veure si Caddy va arrencar després d’un reinici nocturn Com que has vist activitat de matinada, mirem el boot actual: ```bash root@Vhost:~# journalctl -b --no-pager | grep -i caddy ``` També podem mirar reinicis anteriors: ```bash root@Vhost:~# journalctl --list-boots ``` Això mostrarà una llista de boots. Exemple: ```text -1 boot anterior 0 boot actual ``` Podem mirar Caddy al boot anterior: ```bash root@Vhost:~# journalctl -u caddy -b -1 --no-pager ``` I al boot actual: ```bash root@Vhost:~# journalctl -u caddy -b 0 --no-pager ``` ## 9. Veure si algun timer o procés ha tocat Caddy Llistem timers actius: ```bash root@Vhost:~# systemctl list-timers --all ``` Busquem coses relacionades amb Caddy o renovació de certificats: ```bash root@Vhost:~# systemctl list-timers --all | grep -Ei 'caddy|cert|renew|letsencrypt' ``` Caddy normalment no necessita un timer extern de renovació com Certbot, perquè gestiona certificats ell mateix. Però pot haver-hi algun timer o script del sistema. ## 10. Veure si Caddy està instal·lat com a paquet ```bash root@Vhost:~# dpkg -l | grep caddy ``` També podem mirar quan es va instal·lar: ```bash root@Vhost:~# grep -i caddy /var/log/apt/history.log ``` Si els logs estan rotats: ```bash root@Vhost:~# zgrep -i caddy /var/log/apt/history.log* ``` Això pot dir-nos si Caddy es va instal·lar en una sessió anterior del projecte. ## 11. Veure la configuració actual de Caddy ```bash root@Vhost:~# ls -lna /etc/caddy ``` ```bash root@Vhost:~# cat /etc/caddy/Caddyfile ``` Això ens dirà quins dominis està servint actualment. És important perquè potser Caddy ja està publicant altres serveis del CT. ## 12. Veure si Caddy té fitxers de configuració alternatius Busquem referències: ```bash root@Vhost:~# grep -R "reverse_proxy\|:80\|:443\|tls\|http://" /etc/caddy /etc/systemd/system /lib/systemd/system 2>/dev/null ``` Això pot mostrar: ```text quins dominis serveix a quins backends fa proxy si hi ha configuracions personalitzades ``` ## 13. Veure si Apache està habilitat també al boot Per saber si hi ha conflicte permanent entre Apache i Caddy: ```bash root@Vhost:~# systemctl is-enabled apache2 ``` I: ```bash root@Vhost:~# systemctl status apache2 ``` Si tots dos estan habilitats: ```text caddy enabled apache2 enabled ``` llavors al boot poden competir pels ports 80/443. ## 14. Diagnosi probable Si `systemctl status caddy` mostra: ```text Loaded: loaded (...; enabled; ...) Active: active (running) since ... ``` aleshores la resposta és: ```text Caddy s’ha disparat perquè està habilitat com a servei systemd. Ha arrencat automàticament en reiniciar el CT/màquina. ``` Això explicaria que després del reinici nocturn Caddy hagi recuperat els ports 80 i 443. ## 15. Comandes mínimes que cal executar ara ```bash root@Vhost:~# systemctl status caddy ``` ```bash root@Vhost:~# systemctl is-enabled caddy ``` ```bash root@Vhost:~# pstree -sp 1311928 ``` ```bash root@Vhost:~# journalctl -u caddy -b --no-pager ``` ```bash root@Vhost:~# cat /etc/caddy/Caddyfile ``` ```bash root@Vhost:~# systemctl is-enabled apache2 ``` ## 16. Possibles conclusions ### Cas A: Caddy està enabled Conclusió: ```text Caddy arrenca automàticament al boot. ``` Si volem fer servir Apache, caldrà desactivar Caddy: ```bash root@Vhost:~# systemctl disable --now caddy ``` Després: ```bash root@Vhost:~# systemctl restart apache2 ``` ### Cas B: Caddy està disabled però actiu Conclusió: ```text Algú l’ha iniciat manualment o algun altre servei l’ha cridat. ``` Caldrà mirar: ```bash root@Vhost:~# journalctl -u caddy -b --no-pager ``` i: ```bash root@Vhost:~# pstree -sp 1311928 ``` ### Cas C: Caddy no és servei systemd normal Si `systemctl status caddy` no troba el servei, però el procés existeix, caldrà mirar d’on surt: ```bash root@Vhost:~# ps aux | grep caddy ``` ```bash root@Vhost:~# readlink -f /proc/1311928/exe ``` ```bash root@Vhost:~# cat /proc/1311928/cmdline | tr '\0' ' ' ``` ## 17. Decisió pendent Encara no decidim si ens quedem amb Caddy o Apache. Primer documentem qui ha aixecat Caddy. Després decidirem: ```text Opció A: Caddy com a frontal únic Opció B: Apache com a frontal únic i Caddy desactivat ``` ////////////// està clar que el caddy era una rèmora de test d'uns continers que es van quedar funcionant "sols" ///////////// queden purgats i seguim # Publicació de PeerTube darrere Apache Reverse Proxy ## 1. Arquitectura final L’escenari queda així: ```text Internet | | HTTPS / 443 v CT Vhost - Apache + Certbot | | HTTP intern v VM PeerTube 192.168.100.111:9000 ``` PeerTube no publica directament HTTPS a Internet. PeerTube escolta internament a: ```text http://192.168.100.111:9000 ``` Apache fa de frontal públic: ```text https://DOMINI_PEERTUBE ``` ## 2. Comprovació prèvia del backend PeerTube Des del CT `Vhost`: ```bash root@Vhost:~# curl -I http://192.168.100.111:9000 ``` Resultat esperat: ```text HTTP/1.1 200 OK x-powered-by: PeerTube ``` Això confirma que Apache pot arribar al backend. ## 3. Activar mòduls necessaris d’Apache PeerTube necessita Apache com a reverse proxy HTTP. Activem els mòduls bàsics: ```bash root@Vhost:~# a2enmod proxy root@Vhost:~# a2enmod proxy_http root@Vhost:~# a2enmod proxy_wstunnel root@Vhost:~# a2enmod headers root@Vhost:~# a2enmod ssl root@Vhost:~# a2enmod rewrite ``` També pot ser útil: ```bash root@Vhost:~# a2enmod http2 ``` Comprovem sintaxi: ```bash root@Vhost:~# apache2ctl configtest ``` Resultat esperat: ```text Syntax OK ``` Recarreguem Apache: ```bash root@Vhost:~# systemctl reload apache2 ``` ## 4. VirtualHost HTTP inicial Abans de Certbot, podem crear un VirtualHost HTTP senzill. Fitxer: ```text /etc/apache2/sites-available/peertube.conf ``` Crear-lo: ```bash root@Vhost:~# nano /etc/apache2/sites-available/peertube.conf ``` Contingut inicial: ```apache ServerName DOMINI_PEERTUBE ProxyPreserveHost On ProxyRequests Off ProxyPass / http://192.168.100.111:9000/ ProxyPassReverse / http://192.168.100.111:9000/ RequestHeader set X-Forwarded-Proto "http" RequestHeader set X-Forwarded-Port "80" RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s" ErrorLog ${APACHE_LOG_DIR}/peertube-error.log CustomLog ${APACHE_LOG_DIR}/peertube-access.log combined ``` Activem el site: ```bash root@Vhost:~# a2ensite peertube.conf ``` Comprovem: ```bash root@Vhost:~# apache2ctl configtest ``` Recarreguem: ```bash root@Vhost:~# systemctl reload apache2 ``` Prova HTTP: ```bash root@Vhost:~# curl -I http://DOMINI_PEERTUBE ``` Resultat esperat: ```text HTTP/1.1 200 OK x-powered-by: PeerTube ``` ## 5. Certificat TLS amb Certbot Quan HTTP ja funciona, demanem el certificat: ```bash root@Vhost:~# certbot --apache -d DOMINI_PEERTUBE ``` Certbot crearà o modificarà el VirtualHost SSL. Després comprovem: ```bash root@Vhost:~# apache2ctl configtest ``` ```bash root@Vhost:~# systemctl reload apache2 ``` Prova HTTPS: ```bash root@Vhost:~# curl -I https://DOMINI_PEERTUBE ``` ## 6. VirtualHost HTTPS recomanat Després de Certbot, el fitxer pot quedar repartit entre: ```text /etc/apache2/sites-available/peertube.conf /etc/apache2/sites-available/peertube-le-ssl.conf ``` La part HTTPS hauria de quedar semblant a això: ```apache ServerName DOMINI_PEERTUBE Protocols h2 http/1.1 ProxyPreserveHost On ProxyRequests Off # Permet pujades grans de vídeo. LimitRequestBody 0 # Timeouts llargs per pujades, importacions i transcodificació. ProxyTimeout 600 Timeout 600 # Capçaleres importants perquè PeerTube sàpiga que està darrere HTTPS. RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s" RequestHeader set X-Real-IP "%{REMOTE_ADDR}s" # Proxy principal cap a PeerTube. ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ ErrorLog ${APACHE_LOG_DIR}/peertube-ssl-error.log CustomLog ${APACHE_LOG_DIR}/peertube-ssl-access.log combined SSLCertificateFile /etc/letsencrypt/live/DOMINI_PEERTUBE/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMINI_PEERTUBE/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` ## 7. Redirecció HTTP cap a HTTPS El VirtualHost de port 80 pot quedar només com a redirecció: ```apache ServerName DOMINI_PEERTUBE RewriteEngine On RewriteCond %{SERVER_NAME} =DOMINI_PEERTUBE RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] ErrorLog ${APACHE_LOG_DIR}/peertube-error.log CustomLog ${APACHE_LOG_DIR}/peertube-access.log combined ``` ## 8. WebSocket PeerTube normalment funciona bé amb el reverse proxy HTTP, però si detectem problemes amb WebSocket o connexions persistents, podem afegir regles específiques. Primer assegurem el mòdul: ```bash root@Vhost:~# a2enmod proxy_wstunnel ``` Una versió amb detecció d’upgrade seria: ```apache RewriteEngine On RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L] ``` I després mantenim el proxy HTTP normal: ```apache ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ ``` Això quedaria dins del VirtualHost HTTPS. ## 9. Límit de mida de pujada Per evitar problemes pujant vídeos grans: ```apache LimitRequestBody 0 ``` Això vol dir que Apache no imposa un límit propi de mida. També és útil tenir timeouts llargs: ```apache ProxyTimeout 600 Timeout 600 ``` Si es preveuen pujades molt lentes o fitxers molt grossos, podem pujar-ho a: ```apache ProxyTimeout 1800 Timeout 1800 ``` ## 10. Configuració PeerTube `.env` A la VM PeerTube, cal que el `.env` reflecteixi que el servei públic va per HTTPS. Fitxer: ```text /opt/peertube/.env ``` Valors importants: ```env PEERTUBE_WEBSERVER_HOSTNAME=DOMINI_PEERTUBE PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true ``` També cal confiar en el proxy Apache. Si el CT `Vhost` té, per exemple, la IP: ```text 192.168.100.104 ``` la línia hauria de ser: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` Després de canviar el `.env`: ```bash root@peer-tube:/opt/peertube# docker compose down root@peer-tube:/opt/peertube# docker compose up -d ``` O, si volem fer només restart: ```bash root@peer-tube:/opt/peertube# docker compose restart peertube ``` ## 11. Fitxer Apache final compacte Fitxer recomanat: ```text /etc/apache2/sites-available/peertube.conf ``` Contingut complet: ```apache ServerName DOMINI_PEERTUBE RewriteEngine On RewriteCond %{SERVER_NAME} =DOMINI_PEERTUBE RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] ErrorLog ${APACHE_LOG_DIR}/peertube-error.log CustomLog ${APACHE_LOG_DIR}/peertube-access.log combined ServerName DOMINI_PEERTUBE Protocols h2 http/1.1 ProxyPreserveHost On ProxyRequests Off LimitRequestBody 0 ProxyTimeout 600 Timeout 600 RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s" RequestHeader set X-Real-IP "%{REMOTE_ADDR}s" RewriteEngine On RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L] ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ ErrorLog ${APACHE_LOG_DIR}/peertube-ssl-error.log CustomLog ${APACHE_LOG_DIR}/peertube-ssl-access.log combined SSLCertificateFile /etc/letsencrypt/live/DOMINI_PEERTUBE/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMINI_PEERTUBE/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` ## 12. Activació final ```bash root@Vhost:~# a2enmod proxy proxy_http proxy_wstunnel headers ssl rewrite http2 ``` ```bash root@Vhost:~# a2ensite peertube.conf ``` ```bash root@Vhost:~# apache2ctl configtest ``` Resultat esperat: ```text Syntax OK ``` ```bash root@Vhost:~# systemctl reload apache2 ``` ## 13. Proves finals Des del CT `Vhost`: ```bash root@Vhost:~# curl -I http://192.168.100.111:9000 ``` ```bash root@Vhost:~# curl -I https://DOMINI_PEERTUBE ``` Des de fora: ```bash curl -I https://DOMINI_PEERTUBE ``` Resultat esperat: ```text HTTP/2 200 x-powered-by: PeerTube ``` O bé: ```text HTTP/1.1 200 OK x-powered-by: PeerTube ``` segons si HTTP/2 queda actiu. ## 14. Logs útils Apache: ```bash root@Vhost:~# tail -f /var/log/apache2/peertube-ssl-error.log ``` ```bash root@Vhost:~# tail -f /var/log/apache2/peertube-ssl-access.log ``` PeerTube: ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` ## 15. Renovació de certificat Certbot instal·la normalment renovació automàtica. Comprovació: ```bash root@Vhost:~# systemctl list-timers | grep certbot ``` Prova de renovació: ```bash root@Vhost:~# certbot renew --dry-run ``` ## 16. Estat final esperat ```text Vhost: Apache actiu Certbot actiu ports 80/443 ocupats per apache2 PeerTube: Docker actiu a la VM 192.168.100.111 backend intern a port 9000 Publicació: https://DOMINI_PEERTUBE Capçaleres: X-Forwarded-Proto=https X-Forwarded-Port=443 X-Forwarded-For X-Real-IP Pujades: LimitRequestBody 0 ProxyTimeout ampliat ``` # Incidència durant la recreació del desplegament PeerTube Durant la recreació d’una instància prèvia de PeerTube es va reutilitzar una configuració anterior del VirtualHost d’Apache. La configuració era substancialment correcta: `ProxyPass`, `ProxyPassReverse`, capçaleres `X-Forwarded-*`, TLS amb Certbot i límits adequats per a la publicació de vídeo. La incidència no va estar causada directament per PeerTube, sinó per l’estat previ del servidor `Vhost`. ## Origen de la incidència El servidor `Vhost` contenia encara restes d’un desplegament Docker antic, relacionat amb proves de Snikket/XMPP i altres serveis com Caddy, Bluesky PDS i Watchtower. Aquest stack havia quedat residual al servidor des de proves anteriors. En condicions normals no interferia perquè Apache ocupava els ports públics: ```text 80/tcp 443/tcp ``` Però en algun moment del procés —probablement durant una aturada, reload fallit o recreació de configuració d’Apache/Certbot— Apache va deixar lliures aquests ports. En aquell moment, un contenidor Caddy gestionat per Docker/containerd va ocupar `80` i `443`. Això va provocar que Apache ja no pogués tornar a arrencar correctament. ## Símptoma observat Apache fallava amb errors de tipus: ```text Address already in use could not bind to address 0.0.0.0:80 could not bind to address [::]:80 no listening sockets available ``` Inicialment semblava un problema d’Apache, de Certbot o del VirtualHost de PeerTube. Però la comprovació dels ports va revelar que qui ocupava `80` i `443` era `caddy`: ```text users:(("caddy",pid=...,fd=...)) ``` ## Diagnosi real La comprovació amb `systemctl` va mostrar que no hi havia cap servei `caddy.service` instal·lat al sistema: ```bash systemctl status caddy ``` retornava: ```text Unit caddy.service could not be found. ``` Però l’arbre de processos mostrava: ```text systemd └── containerd-shim └── caddy ``` Això confirmava que Caddy no era un servei del sistema, sinó un procés dins d’un contenidor Docker. Posteriorment, `docker ps` va revelar contenidors antics relacionats amb: ```text caddy pds watchtower snikket snikket-proxy snikket-portal snikket-certs ``` ## Causa profunda La causa profunda era la coexistència no desitjada de dos mecanismes de publicació web al mateix host: ```text Apache + Certbot Docker/Caddy/Snikket ``` Tots dos volien fer servir els mateixos ports públics: ```text 80 443 ``` Això és incompatible si no hi ha una decisió explícita sobre quin servei fa de frontal principal. ## Neteja realitzada La incidència va servir per detectar i eliminar configuració residual antiga, no només sobrera sinó realment problemàtica. Es va decidir eliminar el Docker residual del `Vhost`, incloent contenidors antics i restes de Snikket/Caddy/PDS/Watchtower. Això va permetre recuperar el model net: ```text Vhost = Apache + Certbot PeerTube = VM separada amb Docker ``` ## Sobre Certbot i la configuració reciclada En recrear el desplegament de PeerTube es va reutilitzar un `.conf` anterior del VirtualHost. A més, s’havien eliminat certificats creats per Certbot, però havien quedat línies dins la configuració d’Apache que encara apuntaven a aquests certificats. Aquest és un cas típic: ```apache SSLCertificateFile /etc/letsencrypt/live/DOMINI/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMINI/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` Si s’esborra el certificat però queda el VirtualHost SSL apuntant-hi, Apache pot fallar en arrencar o recarregar. Per tant, quan es purga un certificat de Certbot, cal revisar també: ```text /etc/apache2/sites-available/ /etc/apache2/sites-enabled/ ``` i comprovar que no quedin referències a certificats inexistents. ## Comprovacions útils Per detectar referències antigues a certificats: ```bash root@Vhost:~# grep -R "letsencrypt" /etc/apache2/sites-available /etc/apache2/sites-enabled ``` Per veure quins certificats coneix Certbot: ```bash root@Vhost:~# certbot certificates ``` Per eliminar correctament un certificat: ```bash root@Vhost:~# certbot delete --cert-name NOM_CERTIFICAT ``` Per validar Apache després de qualsevol canvi: ```bash root@Vhost:~# apache2ctl configtest ``` Resultat esperat: ```text Syntax OK ``` I després: ```bash root@Vhost:~# systemctl reload apache2 ``` ## Estat final Un cop eliminada la interferència del Docker antic i corregides les referències residuals de Certbot/Apache, el `Vhost` torna a funcionar correctament com a frontal Apache. L’arquitectura queda: ```text Internet | | HTTPS 443 v Apache + Certbot al CT Vhost | | HTTP intern v PeerTube VM 192.168.100.111:9000 ``` I PeerTube queda publicat amb: ```text TLS / certificat ProxyPass ProxyPassReverse X-Forwarded-Proto X-Forwarded-For timeouts amplis límit de pujada adequat ``` ## Lliçó apresa Abans de reutilitzar un host com a reverse proxy, cal comprovar si ja hi ha altres serveis ocupant o intentant ocupar `80/443`. Comandes clau: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` ```bash root@Vhost:~# docker ps ``` ```bash root@Vhost:~# systemctl status apache2 ``` ```bash root@Vhost:~# apache2ctl configtest ``` La incidència ha servit per deixar el servidor més net i evitar futures interferències entre serveis antics i el nou desplegament PeerTube. # Entendre Certbot, Apache i el fitxer `-le-ssl.conf` ## 1. Què passa quan tens un `.cat.conf` Suposem que tens aquest fitxer: ```text /etc/apache2/sites-available/vm.domini.cat.conf ``` Amb un VirtualHost HTTP: ```apache ServerName vm.domini.cat ProxyPreserveHost On ProxyRequests Off ProxyPass / http://192.168.100.111:9000/ ProxyPassReverse / http://192.168.100.111:9000/ ErrorLog ${APACHE_LOG_DIR}/vm.domini.cat-error.log CustomLog ${APACHE_LOG_DIR}/vm.domini.cat-access.log combined ``` Quan executes: ```bash root@Vhost:~# certbot --apache -d vm.domini.cat ``` Certbot fa diverses coses: ```text 1. Llegeix la configuració d’Apache. 2. Busca un VirtualHost que tingui ServerName vm.domini.cat. 3. Intenta validar el domini per HTTP, normalment pel port 80. 4. Demana el certificat a Let’s Encrypt. 5. Escriu o modifica configuració Apache per activar SSL. 6. Recarrega Apache. ``` ## 2. Per què apareix `-le-ssl.conf` Quan Certbot troba un VirtualHost `*:80` però no troba un VirtualHost SSL equivalent, sovint crea un fitxer nou: ```text /etc/apache2/sites-available/vm.domini.cat-le-ssl.conf ``` Aquest fitxer sol contenir el VirtualHost HTTPS: ```apache ServerName vm.domini.cat SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` Per tant, sí: el `-le-ssl.conf` **complementa** el `.conf` original. Normalment queda així: ```text vm.domini.cat.conf → VirtualHost *:80 vm.domini.cat-le-ssl.conf → VirtualHost *:443 ``` ## 3. Què passa si el `.conf` ja té `*:443` Si el teu fitxer original ja conté això: ```apache ServerName vm.domini.cat ... ServerName vm.domini.cat ... ``` Certbot pot fer una de dues coses: ```text 1. Modificar el bloc *:443 existent. 2. Crear igualment un -le-ssl.conf si no sap encaixar bé la configuració. ``` Aquí és on poden començar els embolics. Per exemple, pots acabar tenint **dos VirtualHosts per al mateix domini i port 443**: ```text vm.domini.cat.conf → → ServerName vm.domini.cat vm.domini.cat-le-ssl.conf → → ServerName vm.domini.cat ``` Això no sempre fa petar Apache, però pot fer que Apache triï un VirtualHost que no és el que esperaves. ## 4. La línia `Include /etc/letsencrypt/options-ssl-apache.conf` Aquesta línia: ```apache Include /etc/letsencrypt/options-ssl-apache.conf ``` inclou paràmetres SSL recomanats per Certbot. Normalment defineix coses com: ```text protocols TLS ciphers opcions SSL headers relacionats amb SSL ``` Però no és el certificat en si. Les línies realment vinculades al certificat són aquestes: ```apache SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem ``` Si aquestes apunten a fitxers inexistents, Apache falla. ## 5. Què vol dir “línia vídua” En el teu cas, la línia vídua era: ```apache Include /etc/letsencrypt/options-ssl-apache.conf ``` Això vol dir que havia quedat una resta de configuració Certbot dins d’un VirtualHost reciclat. Per si sola pot no ser fatal, però indica que aquell fitxer havia estat tractat com a VirtualHost SSL. La situació perillosa és aquesta: ```apache ServerName vm.domini.cat ProxyPass / http://192.168.100.111:9000/ ProxyPassReverse / http://192.168.100.111:9000/ Include /etc/letsencrypt/options-ssl-apache.conf ``` Aquí falta el certificat: ```apache SSLCertificateFile ... SSLCertificateKeyFile ... ``` O bé hi són, però apunten a un certificat esborrat. ## 6. Com mirar què veu Apache realment La comanda clau és: ```bash root@Vhost:~# apache2ctl -S ``` Això et diu: ```text quins VirtualHosts hi ha quin fitxer els defineix quin és el default de cada port si tens duplicats ``` Per exemple: ```text *:80 vm.domini.cat (/etc/apache2/sites-enabled/vm.domini.cat.conf:1) *:443 vm.domini.cat (/etc/apache2/sites-enabled/vm.domini.cat-le-ssl.conf:2) ``` Això seria correcte. Però si veus: ```text *:443 vm.domini.cat (/etc/apache2/sites-enabled/vm.domini.cat.conf:20) *:443 vm.domini.cat (/etc/apache2/sites-enabled/vm.domini.cat-le-ssl.conf:2) ``` aleshores tens duplicació de VirtualHost SSL. ## 7. Model net recomanat Per entendre-ho i evitar embolics, jo faria servir aquest model: ```text Fitxer principal: /etc/apache2/sites-available/vm.domini.cat.conf Conté: VirtualHost *:80 VirtualHost *:443 No faig servir: vm.domini.cat-le-ssl.conf O bé: Fitxer principal: vm.domini.cat.conf → només port 80 Fitxer Certbot: vm.domini.cat-le-ssl.conf → només port 443 Però no barrejaria els dos models. ``` Per a documentació i control manual, jo prefereixo tenir-ho tot en un únic fitxer: ```text /etc/apache2/sites-available/vm.domini.cat.conf ``` i desactivar/eliminar el `-le-ssl.conf` si ja no el vols: ```bash root@Vhost:~# a2dissite vm.domini.cat-le-ssl.conf ``` Després: ```bash root@Vhost:~# apache2ctl configtest root@Vhost:~# systemctl reload apache2 ``` ## 8. El socket: què està passant realment Quan diem: ```apache ProxyPass / http://192.168.100.111:9000/ ``` Apache fa de client HTTP contra PeerTube. L’esquema real és: ```text navegador | | HTTPS | port 443 v Apache al Vhost | | HTTP intern | socket TCP cap a 192.168.100.111:9000 v PeerTube ``` No hi ha cap “volum” de disc compartit entre proxy i VM. El que hi ha és una **passarel·la TCP/HTTP**. Apache rep la petició HTTPS, la desxifra, i obre una connexió HTTP interna cap a: ```text 192.168.100.111:9000 ``` Això és el socket: ```text IP origen: CT Vhost IP destí: 192.168.100.111 Port destí: 9000 Protocol: TCP Aplicació: HTTP ``` ## 9. ProxyPass i ProxyPassReverse Això: ```apache ProxyPass / http://192.168.100.111:9000/ ``` vol dir: ```text tot el que arribi a https://vm.domini.cat/ envia-ho internament a http://192.168.100.111:9000/ ``` Això: ```apache ProxyPassReverse / http://192.168.100.111:9000/ ``` serveix perquè si el backend respon amb capçaleres de redirecció, Apache les corregeixi. Exemple: ```text Backend diu: Location: http://192.168.100.111:9000/login Apache ho transforma en: Location: https://vm.domini.cat/login ``` Això evita que l’usuari vegi URLs internes. ## 10. X-Forwarded-Proto Aquesta és crítica: ```apache RequestHeader set X-Forwarded-Proto "https" ``` PeerTube per dins rep HTTP, perquè Apache li parla per: ```text http://192.168.100.111:9000 ``` Però l’usuari real està entrant per: ```text https://vm.domini.cat ``` Per tant, Apache ha d’avisar PeerTube: ```text ei, encara que jo t’estic parlant per HTTP intern, la connexió pública original era HTTPS ``` Això és `X-Forwarded-Proto`. Si això no està bé, PeerTube pot generar URLs malament: ```text http://vm.domini.cat ``` en comptes de: ```text https://vm.domini.cat ``` ## 11. X-Forwarded-For Aquesta capçalera diu a PeerTube quina era la IP real del client. Sense això, PeerTube només veuria com a client la IP del proxy Apache. Amb: ```apache RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s" ``` o amb configuració equivalent, PeerTube pot saber millor d’on venen les peticions. També és habitual: ```apache RequestHeader set X-Real-IP "%{REMOTE_ADDR}s" ``` ## 12. Timeouts Aquests paràmetres: ```apache ProxyTimeout 600 Timeout 600 ``` volen dir que Apache esperarà més temps abans de tallar connexions lentes o llargues. A PeerTube això té sentit perquè hi ha operacions lentes: ```text pujada de vídeos grans processament importacions connexions llargues respostes lentes del backend ``` Si el timeout és massa curt, pots veure errors tipus: ```text 504 Gateway Timeout proxy timeout connection reset ``` Valors raonables: ```apache ProxyTimeout 600 Timeout 600 ``` Per pujades molt grosses o línies lentes: ```apache ProxyTimeout 1800 Timeout 1800 ``` ## 13. Límit de mida de pujada Això: ```apache LimitRequestBody 0 ``` vol dir: ```text Apache no imposa límit de mida al cos de la petició ``` És important perquè una pujada de vídeo pot ser gran. Sense això, Apache pot tallar abans que PeerTube rebi el fitxer. Ara bé: això només elimina el límit d’Apache. PeerTube, Node, Docker, disc i configuració interna també poden tenir altres límits. ## 14. WebSocket WebSocket és una connexió HTTP que fa un “upgrade” a una connexió persistent. Apache necessita el mòdul: ```bash root@Vhost:~# a2enmod proxy_wstunnel ``` I es pot configurar així: ```apache RewriteEngine On RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L] ``` Això diu: ```text si la petició demana WebSocket, envia-la al backend com a ws:// ``` Però no sempre cal posar-ho si l’aplicació funciona bé només amb HTTP proxy normal. Jo ho deixaria si volem una configuració robusta. ## 15. Configuració Apache neta i comprensible Un model net seria aquest: ```apache ServerName vm.domini.cat RewriteEngine On RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] ErrorLog ${APACHE_LOG_DIR}/vm.domini.cat-error.log CustomLog ${APACHE_LOG_DIR}/vm.domini.cat-access.log combined ServerName vm.domini.cat Protocols h2 http/1.1 ProxyPreserveHost On ProxyRequests Off LimitRequestBody 0 ProxyTimeout 600 Timeout 600 RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s" RequestHeader set X-Real-IP "%{REMOTE_ADDR}s" RewriteEngine On RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L] ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ ErrorLog ${APACHE_LOG_DIR}/vm.domini.cat-ssl-error.log CustomLog ${APACHE_LOG_DIR}/vm.domini.cat-ssl-access.log combined SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` ## 16. Ordre mental correcta Jo ho pensaria així: ```text 1. El VirtualHost *:80 existeix perquè Let’s Encrypt pugui validar i perquè puguem redirigir a HTTPS. 2. El VirtualHost *:443 existeix perquè és el servei real publicat. 3. Certbot pot crear el *:443 automàticament en un fitxer -le-ssl.conf. 4. Si volem control manual, podem consolidar-ho tot en un únic .conf. 5. Les línies SSLCertificateFile i SSLCertificateKeyFile són les que lliguen Apache amb el certificat. 6. La línia Include options-ssl-apache.conf només carrega opcions SSL recomanades. 7. ProxyPass és el túnel HTTP cap a PeerTube. 8. ProxyPassReverse arregla redireccions internes. 9. X-Forwarded-Proto informa PeerTube que l’usuari venia per HTTPS. 10. Timeout i LimitRequestBody eviten que Apache talli pujades grosses o connexions lentes. ``` ## 17. Comandes de control Per veure si hi ha certificats: ```bash root@Vhost:~# certbot certificates ``` Per veure si Apache té duplicats: ```bash root@Vhost:~# apache2ctl -S ``` Per veure referències a Let’s Encrypt: ```bash root@Vhost:~# grep -R "letsencrypt" /etc/apache2/sites-available /etc/apache2/sites-enabled ``` Per validar abans de recarregar: ```bash root@Vhost:~# apache2ctl configtest ``` Per veure qui ocupa ports: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` ## 18. Conclusió curta La teva idea és correcta: ```text Certbot crea el -le-ssl.conf segons el que troba al .conf original. ``` Si troba només `*:80`, crea el complement `*:443`. Si ja troba `*:443`, pot modificar-lo o embolicar-se segons com estigui estructurat. Per això, en servidors que reutilitzem sovint, és molt important mirar: ```bash apache2ctl -S ``` i netejar línies velles de: ```apache SSLCertificateFile SSLCertificateKeyFile Include /etc/letsencrypt/options-ssl-apache.conf ``` quan reciclem VirtualHosts. [queda tallat !!!] t'ho acabo jo: quan reciclem hi ha perill # Consolidació del VirtualHost Apache de PeerTube en un únic `.conf` ## 1. Objectiu Volem passar d’un esquema generat/fragmentat per Certbot: ```text vm.domini.cat.conf → VirtualHost *:80 vm.domini.cat-le-ssl.conf → VirtualHost *:443 generat per Certbot ``` a un esquema més net i controlat manualment: ```text vm.domini.cat.conf ├── VirtualHost *:80 └── VirtualHost *:443 ``` És a dir: un únic fitxer Apache site que contingui tant la redirecció HTTP com el reverse proxy HTTPS cap a PeerTube. L’arquitectura final queda: ```text Internet | | HTTPS 443 v Apache al CT Vhost | | HTTP intern v PeerTube VM 192.168.100.111:9000 ``` --- ## 2. Context de la incidència Durant la recreació del desplegament de PeerTube es va reutilitzar un VirtualHost anterior. La configuració reciclada contenia restes de configuració de Certbot, especialment línies com: ```apache Include /etc/letsencrypt/options-ssl-apache.conf ``` i, en alguns casos, referències a certificats: ```apache SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem ``` El problema no era només sintàctic. En aquest cas: ```bash root@Vhost:~# apache2ctl configtest ``` podia no petar clarament. Però en el moment del `reload` o del `start`, Apache podia intentar aixecar un VirtualHost SSL incomplet, sense certificat coherent o amb referències residuals. Això deixava Apache en un estat fallit. En quedar lliures temporalment els ports: ```text 80 443 ``` un contenidor Caddy antic, procedent d’un stack Docker/Snikket abandonat, va ocupar-los. Per això l’error final semblava un problema d’Apache o Certbot, però en realitat era una combinació de: ```text VirtualHost SSL reciclat/inconsistent + certificats Certbot esborrats o referències vídues + Docker antic amb Caddy ocupant 80/443 ``` --- ## 3. Què fa Certbot habitualment Quan tenim un fitxer Apache inicial com aquest: ```text /etc/apache2/sites-available/vm.domini.cat.conf ``` amb un bloc HTTP: ```apache ServerName vm.domini.cat ... ``` i executem: ```bash root@Vhost:~# certbot --apache -d vm.domini.cat ``` Certbot busca un VirtualHost que coincideixi amb: ```apache ServerName vm.domini.cat ``` Si troba un bloc `*:80`, però no troba un bloc SSL clar, normalment crea un fitxer nou: ```text /etc/apache2/sites-available/vm.domini.cat-le-ssl.conf ``` Aquest fitxer conté el VirtualHost HTTPS: ```apache ServerName vm.domini.cat SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` Això vol dir que, per defecte, Certbot pot deixar l’estructura així: ```text vm.domini.cat.conf → port 80 vm.domini.cat-le-ssl.conf → port 443 ``` Això és funcional, però pot ser més incòmode de mantenir quan estem reciclant VirtualHosts o fent desplegaments de prova. --- ## 4. Model que volem deixar Volem deixar un únic fitxer: ```text /etc/apache2/sites-available/vm.domini.cat.conf ``` amb aquesta estructura: ```apache ... ... ``` El bloc `*:80` només redirigeix a HTTPS. El bloc `*:443` és el reverse proxy real cap a PeerTube. --- ## 5. Configuració Apache consolidada Fitxer: ```text /etc/apache2/sites-available/vm.domini.cat.conf ``` Contingut recomanat: ```apache ServerAdmin xab ServerName vm.domini.cat ServerAlias www.vm.domini.cat RewriteEngine On RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] ErrorLog ${APACHE_LOG_DIR}/peertubeVM_80_error.log CustomLog ${APACHE_LOG_DIR}/peertubeVM_80_access.log combined ServerAdmin xab ServerName vm.domini.cat ServerAlias www.vm.domini.cat Protocols h2 http/1.1 # Uploads sense límit imposat per Apache LimitRequestBody 0 # Timeouts llargs per pujades, importacions i connexions lentes ProxyTimeout 600 Timeout 600 # Reverse proxy ProxyPreserveHost On ProxyRequests Off # Capçaleres perquè PeerTube entengui la connexió pública real RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" RequestHeader set X-Forwarded-Host "%{HTTP_HOST}s" RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s" RequestHeader set X-Real-IP "%{REMOTE_ADDR}s" # WebSocket, només si PeerTube o alguna funció ho necessita RewriteEngine On RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L] # Proxy principal cap a PeerTube ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ # Logs ErrorLog ${APACHE_LOG_DIR}/peertubeVM_443_error.log CustomLog ${APACHE_LOG_DIR}/peertubeVM_443_access.log combined # SSL configuration SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` --- ## 6. Correccions aplicades respecte al bloc inicial ### 6.1. Eliminar `ProxyPass` duplicat No convé tenir això dues vegades: ```apache ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ ProxyPass / http://192.168.100.111:9000/ ProxyPassReverse / http://192.168.100.111:9000/ ``` Deixem només: ```apache ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ProxyPassReverse / http://192.168.100.111:9000/ ``` Així Apache té una sola regla clara per passar-ho tot cap a PeerTube. --- ### 6.2. Corregir `X-Forwarded-Host` No deixem aquesta línia buida: ```apache RequestHeader set X-Forwarded-Host "" ``` Això pot confondre el backend. Millor: ```apache RequestHeader set X-Forwarded-Host "%{HTTP_HOST}s" ``` O, en alguns escenaris, simplement es podria eliminar perquè: ```apache ProxyPreserveHost On ``` ja conserva la capçalera `Host`. Però si volem deixar-ho explícit: ```apache RequestHeader set X-Forwarded-Host "%{HTTP_HOST}s" ``` és més clar. --- ### 6.3. Separar logs de port 80 i port 443 És útil tenir logs separats: ```apache ErrorLog ${APACHE_LOG_DIR}/peertubeVM_80_error.log CustomLog ${APACHE_LOG_DIR}/peertubeVM_80_access.log combined ``` i: ```apache ErrorLog ${APACHE_LOG_DIR}/peertubeVM_443_error.log CustomLog ${APACHE_LOG_DIR}/peertubeVM_443_access.log combined ``` Això ajuda a distingir: ```text errors de redirecció HTTP errors del reverse proxy HTTPS problemes de certificat problemes de backend PeerTube ``` --- ## 7. Desmuntar el sistema de dos fitxers Primer mirem què veu Apache: ```bash root@Vhost:~# apache2ctl -S ``` Ens interessa detectar si hi ha dos fitxers actius per al mateix domini: ```text vm.domini.cat.conf vm.domini.cat-le-ssl.conf ``` Si volem consolidar-ho tot en un únic fitxer, desactivem el fitxer `-le-ssl.conf`: ```bash root@Vhost:~# a2dissite vm.domini.cat-le-ssl.conf ``` Ens assegurem que el fitxer principal està actiu: ```bash root@Vhost:~# a2ensite vm.domini.cat.conf ``` Activem els mòduls necessaris: ```bash root@Vhost:~# a2enmod proxy proxy_http proxy_wstunnel headers ssl rewrite http2 ``` Validem configuració: ```bash root@Vhost:~# apache2ctl configtest ``` Resultat esperat: ```text Syntax OK ``` Recarreguem Apache: ```bash root@Vhost:~# systemctl reload apache2 ``` --- ## 8. Comprovar que no queda duplicació Després del canvi: ```bash root@Vhost:~# apache2ctl -S ``` El resultat bo hauria de ser semblant a: ```text *:80 vm.domini.cat (/etc/apache2/sites-enabled/vm.domini.cat.conf:1) *:443 vm.domini.cat (/etc/apache2/sites-enabled/vm.domini.cat.conf:13) ``` No hauria d’aparèixer: ```text vm.domini.cat-le-ssl.conf ``` Si apareix, encara està activat o hi ha un enllaç dins: ```text /etc/apache2/sites-enabled/ ``` Es pot revisar amb: ```bash root@Vhost:~# ls -l /etc/apache2/sites-enabled/ ``` --- ## 9. Buscar restes de Certbot o certificats antics Per veure referències a Let’s Encrypt dins els sites actius: ```bash root@Vhost:~# grep -R "letsencrypt" /etc/apache2/sites-enabled/ ``` Per veure referències a certificats: ```bash root@Vhost:~# grep -R "SSLCertificate" /etc/apache2/sites-enabled/ ``` Per veure qualsevol referència al domini: ```bash root@Vhost:~# grep -R "vm.domini.cat" /etc/apache2/sites-enabled/ ``` També és útil mirar tant `sites-available` com `sites-enabled`: ```bash root@Vhost:~# grep -R "vm.domini.cat\|letsencrypt\|SSLCertificate" /etc/apache2/sites-available /etc/apache2/sites-enabled ``` --- ## 10. Comprovar certificats existents Certbot pot tenir o no tenir el certificat registrat. Comprovem: ```bash root@Vhost:~# certbot certificates ``` Si el certificat existeix, hauríem de veure alguna cosa semblant a: ```text Certificate Name: vm.domini.cat Domains: vm.domini.cat Expiry Date: ... Certificate Path: /etc/letsencrypt/live/vm.domini.cat/fullchain.pem Private Key Path: /etc/letsencrypt/live/vm.domini.cat/privkey.pem ``` Aquests camins han de coincidir amb el VirtualHost: ```apache SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem ``` Si els fitxers no existeixen, Apache no podrà aixecar correctament el VirtualHost SSL. Comprovació directa: ```bash root@Vhost:~# ls -l /etc/letsencrypt/live/vm.domini.cat/ ``` --- ## 11. Si cal recrear el certificat Si el certificat havia estat esborrat, primer podem deixar només el bloc `*:80` actiu o assegurar que el bloc `*:443` no apunta a certificats inexistents. La via neta és: ```bash root@Vhost:~# certbot --apache -d vm.domini.cat ``` Però si vols mantenir el model d’un únic fitxer, després revisa si Certbot t’ha tornat a crear: ```text vm.domini.cat-le-ssl.conf ``` Si l’ha creat, pots tornar a consolidar: ```bash root@Vhost:~# apache2ctl -S root@Vhost:~# a2dissite vm.domini.cat-le-ssl.conf root@Vhost:~# nano /etc/apache2/sites-available/vm.domini.cat.conf root@Vhost:~# apache2ctl configtest root@Vhost:~# systemctl reload apache2 ``` També es pot fer amb `certonly` si prefereixes que Certbot només generi certificat i no toqui Apache: ```bash root@Vhost:~# certbot certonly --apache -d vm.domini.cat ``` Després poses manualment les línies: ```apache SSLCertificateFile /etc/letsencrypt/live/vm.domini.cat/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/vm.domini.cat/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ``` al teu VirtualHost `*:443`. --- ## 12. Explicació de `ProxyPass` Aquesta línia: ```apache ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600 ``` diu a Apache: ```text tot el que arribi a https://vm.domini.cat/ envia-ho internament a http://192.168.100.111:9000/ ``` És una passarel·la HTTP. No comparteix fitxers ni volums. Apache rep una petició HTTPS pública, la desxifra i fa una nova petició HTTP interna cap a la VM PeerTube. --- ## 13. Explicació de `ProxyPassReverse` Aquesta línia: ```apache ProxyPassReverse / http://192.168.100.111:9000/ ``` serveix per corregir redireccions del backend. Per exemple, si PeerTube respongués: ```text Location: http://192.168.100.111:9000/login ``` Apache pot transformar-ho en: ```text Location: https://vm.domini.cat/login ``` Això evita que l’usuari vegi o sigui enviat cap a la IP interna. --- ## 14. Explicació de les capçaleres `X-Forwarded-*` PeerTube rep trànsit intern per HTTP: ```text http://192.168.100.111:9000 ``` Però l’usuari real entra per HTTPS: ```text https://vm.domini.cat ``` Per això Apache ha d’informar PeerTube de la situació real. ### `X-Forwarded-Proto` ```apache RequestHeader set X-Forwarded-Proto "https" ``` Indica que el protocol públic original era HTTPS. Això evita que PeerTube generi URLs amb `http://`. --- ### `X-Forwarded-Port` ```apache RequestHeader set X-Forwarded-Port "443" ``` Indica que el port públic era el 443. --- ### `X-Forwarded-Host` ```apache RequestHeader set X-Forwarded-Host "%{HTTP_HOST}s" ``` Indica quin host havia demanat el client. Per exemple: ```text vm.domini.cat ``` --- ### `X-Forwarded-For` ```apache RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s" ``` Afegeix la IP del client original. Sense això, PeerTube veuria sobretot la IP del proxy Apache. --- ### `X-Real-IP` ```apache RequestHeader set X-Real-IP "%{REMOTE_ADDR}s" ``` Una altra manera habitual d’indicar la IP real del client. --- ## 15. Explicació dels timeouts Aquestes línies: ```apache ProxyTimeout 600 Timeout 600 ``` donen més marge a Apache per esperar respostes del backend. PeerTube pot tenir operacions llargues: ```text pujada de vídeos importació remota transcodificació respostes lentes connexions persistents ``` Amb timeouts massa curts poden aparèixer errors: ```text 504 Gateway Timeout proxy timeout connection reset ``` Un valor de 600 segons és raonable. Si hi ha pujades molt lentes o fitxers molt grans, es podria ampliar: ```apache ProxyTimeout 1800 Timeout 1800 ``` --- ## 16. Explicació de `LimitRequestBody` Aquesta línia: ```apache LimitRequestBody 0 ``` vol dir: ```text Apache no imposa un límit propi a la mida del cos de la petició. ``` Això és important per pujar vídeos grans. Ara bé: això només elimina el límit d’Apache. Encara poden existir altres límits en: ```text PeerTube Node.js Docker disc NFS configuració interna de la instància ``` --- ## 17. Explicació de WebSocket Aquest bloc: ```apache RewriteEngine On RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L] ``` detecta peticions que demanen WebSocket. WebSocket comença com una petició HTTP normal, però demana un canvi de protocol amb: ```text Upgrade: websocket Connection: upgrade ``` Quan Apache detecta això, envia la connexió al backend amb: ```text ws://192.168.100.111:9000/ ``` Per això cal el mòdul: ```bash root@Vhost:~# a2enmod proxy_wstunnel ``` Si PeerTube funciona bé sense aquest bloc, podria no ser necessari. Però deixar-lo configurat és una opció robusta. --- ## 18. Relació amb el `.env` de PeerTube A la VM PeerTube, el fitxer: ```text /opt/peertube/.env ``` ha de ser coherent amb el domini públic. Valors importants: ```env PEERTUBE_WEBSERVER_HOSTNAME=vm.domini.cat PEERTUBE_WEBSERVER_PORT=443 PEERTUBE_WEBSERVER_HTTPS=true ``` També cal que PeerTube confiï en el proxy Apache. Si el CT `Vhost` té, per exemple, la IP: ```text 192.168.100.104 ``` llavors: ```env PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"] ``` Després de canviar `.env`: ```bash root@peer-tube:/opt/peertube# docker compose down root@peer-tube:/opt/peertube# docker compose up -d ``` O bé: ```bash root@peer-tube:/opt/peertube# docker compose restart peertube ``` --- ## 19. Proves del backend PeerTube Des del CT `Vhost`: ```bash root@Vhost:~# curl -I http://192.168.100.111:9000 ``` Resultat esperat: ```text HTTP/1.1 200 OK x-powered-by: PeerTube ``` Això confirma que Apache pot arribar al backend. --- ## 20. Proves del domini públic Prova HTTP: ```bash root@Vhost:~# curl -I http://vm.domini.cat ``` Resultat esperat: ```text HTTP/1.1 301 Moved Permanently Location: https://vm.domini.cat/ ``` Prova HTTPS: ```bash root@Vhost:~# curl -I https://vm.domini.cat ``` Resultat esperat: ```text HTTP/2 200 ``` o: ```text HTTP/1.1 200 OK ``` i idealment alguna capçalera com: ```text x-powered-by: PeerTube ``` --- ## 21. Comprovació de ports ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` Resultat esperat: ```text apache2 ``` No hauria de sortir: ```text caddy docker-proxy nginx ``` --- ## 22. Logs útils Logs Apache del port 80: ```bash root@Vhost:~# tail -f /var/log/apache2/peertubeVM_80_error.log ``` ```bash root@Vhost:~# tail -f /var/log/apache2/peertubeVM_80_access.log ``` Logs Apache del port 443: ```bash root@Vhost:~# tail -f /var/log/apache2/peertubeVM_443_error.log ``` ```bash root@Vhost:~# tail -f /var/log/apache2/peertubeVM_443_access.log ``` Logs PeerTube: ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` --- ## 23. Renovació del certificat Comprovem timers de Certbot: ```bash root@Vhost:~# systemctl list-timers | grep certbot ``` Prova de renovació: ```bash root@Vhost:~# certbot renew --dry-run ``` Si tot està bé, Certbot renovarà el certificat quan pertoqui. Important: encara que consolidem el VirtualHost en un únic fitxer, Certbot pot renovar igualment perquè els certificats continuen vivint a: ```text /etc/letsencrypt/live/vm.domini.cat/ ``` El que cal evitar és que Certbot torni a generar o activar un `-le-ssl.conf` duplicat sense adonar-nos-en. --- ## 24. Checklist final ```bash root@Vhost:~# apache2ctl -S ``` Ha de mostrar només: ```text *:80 vm.domini.cat (...vm.domini.cat.conf...) *:443 vm.domini.cat (...vm.domini.cat.conf...) ``` Validació: ```bash root@Vhost:~# apache2ctl configtest ``` Resultat: ```text Syntax OK ``` Ports: ```bash root@Vhost:~# ss -ltnp | grep -E ':80|:443' ``` Ha de sortir: ```text apache2 ``` Certificat: ```bash root@Vhost:~# certbot certificates ``` Ha d’existir: ```text vm.domini.cat ``` Backend: ```bash root@Vhost:~# curl -I http://192.168.100.111:9000 ``` Domini públic: ```bash root@Vhost:~# curl -I https://vm.domini.cat ``` Docker antic: ```bash root@Vhost:~# docker ps ``` Si Docker ja s’ha purgat, aquesta ordre pot no existir o no retornar res. El que importa és que no hi hagi cap `caddy` ocupant `80/443`. --- ## 25. Resum conceptual El sistema queda així: ```text Apache: escolta a 80 i 443 gestiona TLS amb Certbot redirigeix HTTP cap a HTTPS fa reverse proxy cap a PeerTube PeerTube: escolta internament a 192.168.100.111:9000 sap que el domini públic és vm.domini.cat sap que el públic entra per HTTPS TrueNAS/NFS: conté les dades grosses de vídeo no participa en el reverse proxy Docker antic del Vhost: eliminat o aturat ja no interfereix amb ports 80/443 ``` El punt essencial és: ```text Entre Apache i PeerTube no hi ha volums ni fitxers compartits. Hi ha una connexió HTTP/TCP interna. ``` Els volums grossos són una altra capa: ```text PeerTube VM → NFS → TrueNAS ``` El Vhost només fa de passarel·la web pública. # NEXT — Afinament post-desplegament PeerTube ## 0. Estat actual Tenim operativa aquesta arquitectura: ```text Internet | | HTTPS 443 v Apache + Certbot al CT Vhost | | HTTP intern v PeerTube VM 192.168.100.111:9000 | | NFS v TrueNAS /mnt/AV/VM/peertube ``` El `Vhost` ja funciona i publica la nova instància PeerTube. Ara toca afinar: ```text 1. UID/GID i propietat dels fitxers al TrueNAS 2. SMTP i correu sortint dels contenidors PeerTube 3. Federació / migració / clonació de contingut entre instàncies PeerTube 4. Importació de contingut de YouTube amb yt-dlp / youtube-dl 5. Repàs del full de ruta de desplegament ``` --- # 1. Propietat UID/GID al TrueNAS ## Objectiu Garantir que PeerTube pot escriure correctament al dataset NFS del TrueNAS: ```text /mnt/AV/VM/peertube ``` i especialment a: ```text /mnt/AV/VM/peertube/data ``` A la VM PeerTube aquest dataset entra com: ```text /mnt/truenas-peertube ``` i després PeerTube l’usa mitjançant: ```text /opt/peertube/docker-volume/data -> /mnt/truenas-peertube/data ``` ## Problema típic PeerTube dins Docker no necessàriament escriu com a `root`. Pot escriure amb un UID/GID concret dins del contenidor. Per tant, encara que al TrueNAS sembli que `root` pot escriure, pot passar que el contenidor PeerTube tingui problemes si el UID real que escriu no té permisos. ## Comprovacions A la VM PeerTube: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube root@peer-tube:~# ls -lna /mnt/truenas-peertube/data root@peer-tube:~# ls -lna /opt/peertube/docker-volume ``` Prova d’escriptura des del host VM: ```bash root@peer-tube:~# touch /mnt/truenas-peertube/data/prova-root-vm.txt ``` Prova d’escriptura des del contenidor PeerTube: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube sh ``` Dins del contenidor: ```bash id touch /data/prova-des-del-contenidor.txt ls -lna /data exit ``` Això ens dirà amb quin UID/GID escriu realment PeerTube. ## Acció probable Quan sapiguem el UID/GID real, al TrueNAS podem ajustar propietat: ```bash root@truenas:~# chown -R UID:GID /mnt/AV/VM/peertube/data ``` o bé, si volem una solució més permissiva de laboratori: ```bash root@truenas:~# chmod -R 775 /mnt/AV/VM/peertube ``` Però la solució bona és identificar UID/GID i deixar-ho coherent. --- # 2. SMTP entre contenidors i `.env` ## Objectiu Que PeerTube pugui enviar correus: ```text registre d’usuaris recuperació de contrasenya notificacions moderació confirmacions ``` ## Elements implicats Al `.env` de PeerTube hi ha variables SMTP. Hem de decidir si PeerTube enviarà correu via: ```text 1. contenidor postfix inclòs al docker-compose 2. SMTP extern real 3. SMTP propi del domini 4. relay SMTP d’un proveïdor ``` ## Recomanació Per una instància realista, jo no confiaria massa en un Postfix intern si el domini públic ha d’entregar correu bé. Millor usar SMTP extern autenticat. Exemple conceptual: ```env PEERTUBE_SMTP_HOSTNAME=smtp.domini.cat PEERTUBE_SMTP_PORT=587 PEERTUBE_SMTP_USERNAME=usuari@domini.cat PEERTUBE_SMTP_PASSWORD=PASSWORD PEERTUBE_SMTP_TLS=true PEERTUBE_SMTP_DISABLE_STARTTLS=false PEERTUBE_SMTP_FROM=noreply@domini.cat ``` Cal revisar els noms exactes segons el `.env` oficial que tens descarregat. ## Comprovacions A la VM PeerTube: ```bash root@peer-tube:/opt/peertube# grep -i smtp .env ``` Logs després de modificar SMTP: ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` Reinici del servei: ```bash root@peer-tube:/opt/peertube# docker compose restart peertube ``` ## Prova funcional Des de la interfície web: ```text Administration → Configuration → Email / SMTP ``` o prova de registre / recuperació de contrasenya. També podem mirar si el contenidor intenta connectar: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube sh ``` i dins: ```bash nc -vz smtp.domini.cat 587 ``` si `nc` existeix. --- # 3. Federar / clonar / replicar entre instàncies PeerTube Aquí cal separar conceptes perquè no són exactament el mateix. ## 3.1. Federar Federar vol dir que dues instàncies PeerTube es veuen entre elles via ActivityPub. Això permet: ```text seguir canals remots veure vídeos remots interactuar entre instàncies tenir visibilitat federada ``` Però federar no vol dir clonar tota una instància. ## 3.2. Importar / migrar contingut Això és portar vídeos, metadades o canals d’una instància antiga a una nova. Pot requerir: ```text exportació de base de dades còpia de fitxers ús d’eines internes de PeerTube importació via URL repujada de vídeos ``` ## 3.3. Replicar PeerTube té funcionalitats de redundància/replicació entre instàncies, però no equival exactament a “clonar tota la plataforma”. La replicació pot servir per tenir còpies de vídeos d’una altra instància, però cal configurar-ho bé. ## Objectiu pràctic nostre Tenim una instància antiga en CT i una nova en VM. Volem garantir que és possible: ```text 1. que la nova instància federi amb l’antiga 2. que la nova pugui importar vídeos de l’antiga 3. que, si cal, es pugui migrar contingut 4. que no perdem dades ni fitxers ``` ## Comprovacions inicials A la instància antiga: ```text domini antic estat accés admin volum de vídeos versió PeerTube ``` A la nova: ```text domini nou estat admin versió PeerTube configuració federation enabled ``` A la nova instància cal comprovar: ```text Administration → Configuration → Federation ``` i confirmar que la federació està activa. ## Proves mínimes Des de la nova instància: ```text buscar un canal remot de la instància antiga seguir-lo veure si apareixen vídeos provar importació per URL d’un vídeo públic antic ``` ## Punt important Si el que volem és “clonar” la instància antiga, no ho faria a cegues amb `rsync` de volums i base de dades si la versió, domini i ruta han canviat. Caldria preparar un pla específic de migració: ```text backup DB antiga backup data antiga compatibilitat de versions restauració controlada canvi de domini si aplica regeneració de configuració ``` Però si el que volem és poblar la nova amb contingut seleccionat, és més segur usar importació/federació. --- # 4. Connectar internament amb YouTube / yt-dlp ## Objectiu Volem que els usuaris de PeerTube puguin “agregar contingut” de YouTube als seus perfils. Això normalment vol dir permetre importació per URL externa. PeerTube pot importar vídeos remots si té les eines corresponents disponibles dins del contenidor o en la imatge utilitzada. ## Punt tècnic Actualment el món YouTube canvia sovint i `youtube-dl` queda obsolet ràpidament. El més habitual és usar: ```text yt-dlp ``` Caldrà comprovar si la imatge PeerTube ja porta suport d’importació o si cal adaptar-ho. ## Comprovacions A la interfície d’administració PeerTube: ```text Administration → Configuration → Import ``` Cal buscar opcions com: ```text enable video import enable import via URL allow users to import videos ``` A nivell contenidor: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube sh ``` Dins: ```bash which youtube-dl which yt-dlp yt-dlp --version youtube-dl --version ``` ## Decisió Hi ha dues formes: ```text A. Usar el suport intern de PeerTube si ja funciona. B. Crear una integració controlada amb yt-dlp externa. ``` Per seguretat i manteniment, primer provaria l’opció A. ## Riscos Permetre als usuaris importar contingut de YouTube implica: ```text consum de disc consum de CPU per transcodificació riscos de copyright contingut no desitjat possibles bloquejos o fallades de YouTube cookies si el vídeo requereix sessió ``` Per tant, convé controlar: ```text qui pot importar quota per usuari límit de mida límit de durada moderació ``` --- # 5. Full de ruta de desplegament ## Fase 1 — Infraestructura base Ja feta: ```text VM Ubuntu PeerTube Docker Compose NFS TrueNAS Apache Vhost Certbot/TLS reverse proxy funcional ``` ## Fase 2 — Permisos i persistència Pendent immediat: ```text UID/GID real del contenidor PeerTube propietat del dataset TrueNAS prova d’escriptura des del contenidor prova de pujada real de vídeo verificació de thumbnails, previews, HLS i originals ``` ## Fase 3 — Correu Pendent: ```text decidir SMTP final configurar .env reiniciar PeerTube provar enviament verificar logs ``` ## Fase 4 — Federació i migració Pendent: ```text activar/verificar federació provar seguiment entre instàncies provar importació d’un vídeo antic definir si volem migració completa o només població selectiva ``` ## Fase 5 — Importació YouTube Pendent: ```text comprovar yt-dlp/youtube-dl dins PeerTube activar importació per URL definir permisos d’usuari provar importació d’un vídeo curt revisar consum de disc i CPU ``` ## Fase 6 — Hardening mínim Pendent: ```text firewall bàsic només ports necessaris oberts backups rotació de logs monitoratge d’espai NFS actualitzacions controlades ``` ## Fase 7 — Documentació final Pendent: ```text arquitectura fitxers modificats docker-compose.yml .env anonimitzat fstab NFS Apache vhost procediment de recuperació procediment de migració proves finals ``` --- # 6. Ordre recomanat de treball Jo seguiria aquest ordre: ```text 1. UID/GID i permisos TrueNAS 2. SMTP 3. prova de pujada de vídeo pròpia 4. federació amb instància antiga 5. importació des de la instància antiga 6. importació YouTube / yt-dlp 7. backups i monitoratge ``` La raó és senzilla: ```text sense permisos correctes → no podem confiar en pujades/importacions sense SMTP → la plataforma queda coixa per a usuaris sense proves de pujada → no sabem si NFS/PeerTube funciona del tot sense això estable → no té sentit obrir importacions massives ``` --- # 7. Primer bloc de treball: UID/GID TrueNAS Per començar el NEXT real, jo faria això. A la VM PeerTube: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube id ``` També: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube sh -c 'id && touch /data/prova-des-del-contenidor.txt && ls -lna /data/prova-des-del-contenidor.txt' ``` Després al host VM: ```bash root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube/data ``` I al TrueNAS: ```bash root@truenas:~# ls -lna /mnt/AV/VM/peertube/data ``` Amb això sabrem: ```text quin UID/GID escriu dins el contenidor com apareix al NFS si TrueNAS ho veu igual si cal fer chown o ajustar ACL ``` --- # 8. Segon bloc: SMTP A la VM PeerTube: ```bash root@peer-tube:/opt/peertube# grep -i smtp .env ``` I després decidim si usem: ```text SMTP extern autenticat Postfix intern del compose relay propi ``` La configuració SMTP és millor fer-la després dels permisos, perquè si PeerTube ja pot escriure bé i està estable, els errors que quedin seran només de correu. --- # 9. Tercer bloc: federació i importació Quan permisos i SMTP estiguin tancats: ```text prova de pujada local prova de visualització prova d’importació remota prova de federació amb la instància antiga prova d’importació YouTube ``` No faria importacions grans fins haver validat una pujada petita i una importació curta. --- # 10. NEXT immediat El següent pas concret seria: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube id root@peer-tube:/opt/peertube# docker compose exec peertube sh -c 'touch /data/prova-des-del-contenidor.txt && ls -lna /data/prova-des-del-contenidor.txt' root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube/data ``` A partir d’aquesta sortida decidim el `chown` correcte al TrueNAS. Els fitxers apareixen com `999:999` perquè l’aplicació PeerTube dins del contenidor Docker escriu les dades amb aquest UID/GID. NFS no tradueix aquests valors a “usuaris humans”, sinó que transporta els identificadors numèrics fins al TrueNAS. Per això al NAS poden aparèixer amb noms locals com `netdata` o `docker`, però la dada rellevant és el número `999:999`, visible amb `ls -lna`. El 999 ja existeix com a UID/GID de sistema en diversos llocs, però no representa la mateixa “persona”. És només el mateix número. PeerTube/Docker l’utilitza per les seves dades; NFS conserva el número; TrueNAS i Ubuntu li posen noms locals diferents. # Refinament de permisos del dataset NFS de PeerTube ## 1. Situació inicial Durant la instal·lació inicial de PeerTube es va crear al TrueNAS el directori de dades persistents: ```text /mnt/AV/VM/peertube/data ``` Aquest directori es va crear manualment des del TrueNAS com a `root`, per tant inicialment tenia propietat: ```text 0:0 ``` És a dir: ```text UID 0 → root GID 0 → root ``` En fase de laboratori es van aplicar permisos amplis: ```bash chmod -R 775 /mnt/AV/VM/peertube ``` Això es va fer per garantir que la VM Ubuntu i els contenidors Docker de PeerTube poguessin escriure sobre el muntatge NFS sense quedar bloquejats per permisos abans de validar el funcionament general del servei. Aquest `775` era una configuració provisional de desplegament, útil per arrencar i provar, però no és la configuració final més neta. --- ## 2. Circuit real de dades El circuit de dades és aquest: ```text TrueNAS /mnt/AV/VM/peertube/data | | NFS v VM Ubuntu PeerTube /mnt/truenas-peertube/data | | volum / bind mount Docker v Contenidor PeerTube /data ``` El `Vhost` Apache no accedeix directament als fitxers del NAS. Apache només fa de reverse proxy: ```text Navegador | | HTTPS v Apache Vhost | | HTTP intern v PeerTube VM:9000 ``` Qui llegeix i escriu els fitxers de vídeo, miniatures, HLS, imports i temporals és PeerTube dins del seu contenidor. --- ## 3. Per què apareix `999:999` En inspeccionar `/data` dins del contenidor PeerTube es veu que l’estructura de dades principal apareix com: ```text 999:999 ``` Per exemple: ```text drwxrwxr-x 23 999 999 data drwxr-xr-x 3 999 999 tmp drwxr-xr-x 3 999 999 uploads drwxr-xr-x 6 999 999 cache ``` Això indica que la imatge Docker de PeerTube o el seu procés d’inicialització prepara la carpeta de dades amb l’UID/GID: ```text UID 999 GID 999 ``` Aquests números no són “noms d’usuari universals”. Són identificadors numèrics. NFS transporta aquests identificadors numèrics entre sistemes. Per això, quan PeerTube crea o modifica fitxers com `999:999`, el TrueNAS els desa amb aquests mateixos números. --- ## 4. Per què al TrueNAS pot aparèixer com `netdata:docker` Cada sistema té la seva pròpia taula local d’usuaris i grups: ```text /etc/passwd /etc/group ``` Per tant, el mateix número pot tenir noms diferents segons el sistema. Per exemple: ```text Dins del contenidor: 999:999 pot aparèixer com un usuari intern de l’aplicació o només com número. A la VM Ubuntu: 999 pot correspondre a algun usuari o grup de sistema. Al TrueNAS: UID 999 pot aparèixer com netdata. GID 999 pot aparèixer com docker. ``` Això no vol dir que `netdata` estigui executant PeerTube. Vol dir que el TrueNAS veu el número `999` i el tradueix al nom local que ell té associat a aquest UID/GID. Per evitar confusions, en aquest escenari sempre convé mirar els permisos en format numèric: ```bash ls -lna ``` En comptes de: ```bash ls -la ``` La dada fiable és: ```text 999:999 ``` No el nom local que cada sistema li assigna. --- ## 5. NFS no converteix `0:0` en `999:999` Un punt important és que NFS no transforma automàticament els fitxers `root:root` en `999:999`. Això es va veure clarament quan es va entrar manualment al contenidor: ```bash docker compose exec peertube sh ``` I dins del contenidor: ```bash id ``` va retornar: ```text uid=0(root) gid=0(root) ``` Quan es va crear un fitxer manualment: ```bash touch /data/prova-des-del-contenidor.txt ``` aquest fitxer va aparèixer com: ```text 0:0 ``` Això demostra que si escriu `root`, arriba `root`. Per tant: ```text fitxers 0:0 → els ha creat un procés que escrivia com root fitxers 999:999 → els ha creat o preparat PeerTube/entrypoint amb UID/GID 999 ``` NFS conserva els números que li arriben. --- ## 6. Per què fem `chown -R 999:999` Un cop PeerTube ja ha inicialitzat la seva estructura i veiem que treballa amb `999:999`, la solució coherent és fer que la carpeta de dades del NAS tingui aquesta propietat: ```bash chown -R 999:999 /mnt/AV/VM/peertube/data ``` Això vol dir: ```text la DATA de PeerTube pertany a l’UID 999 i al GID 999 ``` No estem donant permisos a tothom. Estem fent que el propietari del dataset coincideixi amb l’usuari/grup que l’aplicació espera. És una solució millor que mantenir `775`, perquè no depèn de permisos oberts, sinó de propietat correcta. --- ## 7. Diferència entre `chown` i `chmod` ### `chown` Canvia el propietari i el grup: ```bash chown -R 999:999 /mnt/AV/VM/peertube/data ``` Respon a la pregunta: ```text de qui són aquests fitxers? ``` ### `chmod` Canvia els permisos: ```bash chmod 2750 directori chmod 640 fitxer ``` Respon a la pregunta: ```text què pot fer el propietari, el grup i la resta d’usuaris? ``` Per tant, el refinament té dues parts: ```text 1. canviar propietat a 999:999 2. reduir permisos respecte al 775 inicial ``` --- ## 8. Explicació del mode `0775` El mode clàssic de permisos té tres xifres principals: ```text 775 ``` Que volen dir: ```text 7 → propietari 7 → grup 5 → altres ``` Cada xifra és la suma de: ```text 4 → read / lectura 2 → write / escriptura 1 → execute / execució o entrada en directori ``` Per tant: ```text 7 = 4+2+1 = read + write + execute 5 = 4+1 = read + execute ``` Un directori amb `775` queda així: ```text drwxrwxr-x ``` Això vol dir: ```text propietari → pot llegir, escriure i entrar grup → pot llegir, escriure i entrar altres → poden llegir i entrar ``` Funciona en laboratori, però és més permissiu del necessari. --- ## 9. El “quart dígit” de chmod A més de les tres xifres normals, chmod pot tenir una quarta xifra al davant: ```text 2750 ``` Aquest primer dígit activa permisos especials. Els valors són: ```text 4 → setuid 2 → setgid 1 → sticky bit ``` Es poden combinar, igual que els permisos normals. Per exemple: ```text 4755 → setuid 2750 → setgid 1777 → sticky bit ``` --- ## 10. Setuid El bit `setuid` és el valor especial: ```text 4 ``` En fitxers executables, fa que el programa s’executi amb els permisos del propietari del fitxer. Exemple clàssic: ```text /usr/bin/passwd ``` El programa `passwd` necessita modificar fitxers del sistema com `/etc/shadow`, però els usuaris normals no hi poden escriure directament. El bit setuid permet que el programa s’executi amb privilegis controlats. En aquest cas de PeerTube **no necessitem setuid**. Per tant, no farem servir modes tipus: ```text 4750 4640 ``` --- ## 11. Setgid El bit `setgid` és el valor especial: ```text 2 ``` En directoris, és molt útil. Quan un directori té setgid activat, els fitxers i subdirectoris nous tendeixen a heretar el grup del directori pare. Per exemple: ```bash chmod 2750 /mnt/AV/VM/peertube/data ``` El directori queda així: ```text drwxr-s--- ``` La `s` en la part del grup indica que el setgid està activat. Això ajuda a mantenir la coherència del grup: ```text 999 ``` Per això és recomanable per a directoris de dades gestionats per una aplicació. --- ## 12. Sticky bit El sticky bit és el valor especial: ```text 1 ``` És típic en directoris compartits com: ```text /tmp ``` Un directori amb sticky bit pot aparèixer així: ```text drwxrwxrwt ``` Serveix perquè diversos usuaris puguin escriure dins del directori, però no puguin esborrar fitxers d’altres usuaris. En aquest cas de PeerTube **no és necessari**, perquè no volem un directori públic compartit entre molts usuaris de sistema. --- ## 13. Per què `2750` per directoris Els directoris necessiten el bit `x` per poder-hi entrar. Per això un directori massa tancat com: ```text 2640 ``` no és adequat per a directoris, perquè no dona execució/entrada. Per a directoris de PeerTube proposem: ```text 2750 ``` Que equival a: ```text drwxr-s--- ``` Desglossat: ```text 2 → setgid 7 → propietari: lectura, escriptura i entrada 5 → grup: lectura i entrada 0 → altres: cap permís ``` Això permet que l’usuari propietari `999` gestioni les dades, que el grup `999` pugui llegir i entrar, i que la resta d’usuaris no tingui accés. --- ## 14. Per què `640` per fitxers Els fitxers no necessiten el bit `x` si no són executables. Per això proposem: ```text 640 ``` Que equival a: ```text -rw-r----- ``` Desglossat: ```text 6 → propietari: lectura i escriptura 4 → grup: lectura 0 → altres: cap permís ``` Això és suficient per a fitxers de dades, vídeos, miniatures, manifests, temporals i metadades, sempre que PeerTube sigui el procés que els serveix. No cal que “altres” usuaris del sistema puguin llegir directament aquests fitxers. --- ## 15. Per què no `2640` El mode `2640` té sentit sobretot per a fitxers si es volgués activar setgid, però en fitxers normals no aporta el mateix benefici pràctic que en directoris. A més, en directoris seria problemàtic perquè: ```text 2640 ``` equival aproximadament a: ```text drw-r-S--- ``` La `S` majúscula indica que hi ha setgid però falta el bit d’execució del grup. En un directori, sense execució no es pot entrar correctament. Per això: ```text directoris → 2750 fitxers → 640 ``` és molt més net. --- ## 16. Permisos finals proposats Al TrueNAS: ```bash root@truenas:~# chown -R 999:999 /mnt/AV/VM/peertube/data root@truenas:~# find /mnt/AV/VM/peertube/data -type d -exec chmod 2750 {} \; root@truenas:~# find /mnt/AV/VM/peertube/data -type f -exec chmod 640 {} \; ``` Això deixa: ```text directoris → drwxr-s--- fitxers → -rw-r----- propietat → 999:999 ``` --- ## 17. No hauria de trencar PeerTube? No hauria de trencar-lo si PeerTube realment treballa amb `999:999`, com ja hem vist en la seva estructura de `/data`. El canvi fa que les dades siguin propietat de l’UID/GID que PeerTube ja està usant. A més, si hi hagués cap problema, és fàcil revertir temporalment a un mode més permissiu: ```bash root@truenas:~# find /mnt/AV/VM/peertube/data -type d -exec chmod 775 {} \; root@truenas:~# find /mnt/AV/VM/peertube/data -type f -exec chmod 664 {} \; ``` Però la configuració final recomanada és més restrictiva: ```text 2750 per directoris 640 per fitxers ``` --- ## 18. Com validar després del canvi Des del TrueNAS: ```bash root@truenas:~# ls -lna /mnt/AV/VM/peertube/data | head ``` Resultat esperat: ```text drwxr-s--- 999 999 ... ``` Des de la VM PeerTube: ```bash root@peer-tube:~# ls -lna /mnt/truenas-peertube/data | head ``` Buscar fitxers recents: ```bash root@peer-tube:~# find /mnt/truenas-peertube/data -type f -printf '%TY-%Tm-%Td %TH:%TM %U:%G %m %s %p\n' | sort | tail -30 ``` Comprovar que el backend continua funcionant: ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` I des de la web: ```text 1. reproduir un vídeo existent 2. pujar un vídeo curt 3. comprovar miniatura 4. comprovar reproducció ``` --- ## 19. On queden els vídeos pujats Els vídeos no tenen per què aparèixer amb el nom original. PeerTube pot distribuir-los en carpetes com: ```text /mnt/AV/VM/peertube/data/original-video-files /mnt/AV/VM/peertube/data/videos /mnt/AV/VM/peertube/data/streaming-playlists /mnt/AV/VM/peertube/data/thumbnails /mnt/AV/VM/peertube/data/previews /mnt/AV/VM/peertube/data/tmp ``` Per trobar els fitxers recents al TrueNAS: ```bash root@truenas:~# find /mnt/AV/VM/peertube/data -type f -printf '%TY-%Tm-%Td %TH:%TM %U:%G %m %s %p\n' | sort | tail -50 ``` Per veure fitxers grans: ```bash root@truenas:~# find /mnt/AV/VM/peertube/data -type f -size +10M -printf '%TY-%Tm-%Td %TH:%TM %U:%G %m %s %p\n' | sort | tail -30 ``` --- ## 20. Resum final La seqüència correcta és: ```text 1. El dataset es crea al TrueNAS com root:root perquè el crea l’administrador. 2. En laboratori s’aplica 775 per evitar bloquejos inicials. 3. PeerTube inicialitza /data i crea estructura amb UID/GID 999:999. 4. NFS conserva aquests números entre contenidor, VM i TrueNAS. 5. Els noms com netdata/docker/systemd-journal són traduccions locals dels mateixos números. 6. El criteri fiable és mirar sempre amb ls -lna. 7. La configuració final coherent és chown -R 999:999. 8. Els permisos finals recomanats són 2750 per directoris i 640 per fitxers. ``` La idea de fons és: ```text No fem el dataset obert perquè funcioni. Fem que sigui propietat de l’UID/GID que realment l’ha de fer servir. ``` En aquest desplegament: ```text PeerTube /data → 999:999 TrueNAS dataset → 999:999 ``` # Diagnosi SMTP PeerTube: `wrong version number` ## 1. Error observat Als logs de PeerTube apareix: ```text Processing email in job 1. ``` i després: ```text SSL routines:tls_validate_record_header:wrong version number code: ESOCKET command: CONN ``` Això passa quan PeerTube intenta enviar un correu, en aquest cas probablement el correu de recuperació de contrasenya. ## 2. Interpretació Aquest error no sol voler dir que la contrasenya SMTP sigui incorrecta. Tampoc sol voler dir que el servidor SMTP estigui caigut. Normalment vol dir que PeerTube està intentant parlar amb el servidor SMTP amb un mode TLS equivocat. Hi ha dues formes habituals de SMTP segur: ```text Port 587: SMTP normal inicial després STARTTLS no és TLS directe des del primer byte Port 465: SMTPS TLS directe des del començament ``` Si PeerTube intenta TLS directe contra un port 587, el servidor respon amb SMTP normal i OpenSSL diu: ```text wrong version number ``` Perquè esperava una resposta TLS, però ha rebut text SMTP. ## 3. Taula pràctica | Port | Mode correcte | TLS directe | STARTTLS | |---:|---|---|---| | 25 | SMTP clàssic / relay intern | no | opcional | | 587 | Submission | no | sí | | 465 | SMTPS | sí | no | Per tant: ```text 587 → secure false + STARTTLS true 465 → secure true + STARTTLS false ``` ## 4. Què revisar al `.env` A la VM PeerTube: ```bash root@peer-tube:/opt/peertube# grep -i smtp .env ``` Cal mirar especialment: ```env PEERTUBE_SMTP_HOSTNAME= PEERTUBE_SMTP_PORT= PEERTUBE_SMTP_USERNAME= PEERTUBE_SMTP_PASSWORD= PEERTUBE_SMTP_TLS= PEERTUBE_SMTP_DISABLE_STARTTLS= PEERTUBE_SMTP_FROM= ``` Els noms exactes poden variar segons la versió del `.env`, però la idea és aquesta. ## 5. Configuració típica per SMTP port 587 Si el teu servidor SMTP usa el port 587, la configuració hauria de ser d’aquest estil: ```env PEERTUBE_SMTP_HOSTNAME=smtp.domini.cat PEERTUBE_SMTP_PORT=587 PEERTUBE_SMTP_USERNAME=usuari@domini.cat PEERTUBE_SMTP_PASSWORD=CONTRASENYA PEERTUBE_SMTP_TLS=false PEERTUBE_SMTP_DISABLE_STARTTLS=false PEERTUBE_SMTP_FROM=noreply@domini.cat ``` La idea és: ```text TLS directe: no STARTTLS: sí ``` Per això: ```env PEERTUBE_SMTP_TLS=false PEERTUBE_SMTP_DISABLE_STARTTLS=false ``` ## 6. Configuració típica per SMTP port 465 Si el teu servidor SMTP usa el port 465, la configuració hauria de ser: ```env PEERTUBE_SMTP_HOSTNAME=smtp.domini.cat PEERTUBE_SMTP_PORT=465 PEERTUBE_SMTP_USERNAME=usuari@domini.cat PEERTUBE_SMTP_PASSWORD=CONTRASENYA PEERTUBE_SMTP_TLS=true PEERTUBE_SMTP_DISABLE_STARTTLS=true PEERTUBE_SMTP_FROM=noreply@domini.cat ``` La idea és: ```text TLS directe: sí STARTTLS: no ``` ## 7. El cas que probablement tens ara Pel missatge: ```text tls_validate_record_header:wrong version number ``` jo sospito una configuració així: ```text port 587 + TLS directe activat ``` És a dir, probablement tens alguna cosa semblant a: ```env PEERTUBE_SMTP_PORT=587 PEERTUBE_SMTP_TLS=true ``` Això acostuma a petar. Per a port 587, prova: ```env PEERTUBE_SMTP_PORT=587 PEERTUBE_SMTP_TLS=false PEERTUBE_SMTP_DISABLE_STARTTLS=false ``` ## 8. Aplicar canvi Editar `.env`: ```bash root@peer-tube:/opt/peertube# nano .env ``` Després reiniciar PeerTube: ```bash root@peer-tube:/opt/peertube# docker compose restart peertube ``` Si vols reiniciar tot l’stack: ```bash root@peer-tube:/opt/peertube# docker compose down root@peer-tube:/opt/peertube# docker compose up -d ``` Mirar logs: ```bash root@peer-tube:/opt/peertube# docker compose logs -f peertube ``` ## 9. Provar connexió SMTP des del contenidor Primer comprovem connectivitat bàsica. Per port 587: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube sh -c 'nc -vz smtp.domini.cat 587' ``` Per port 465: ```bash root@peer-tube:/opt/peertube# docker compose exec peertube sh -c 'nc -vz smtp.domini.cat 465' ``` Si `nc` no existeix dins del contenidor, es pot provar des de la VM: ```bash root@peer-tube:~# nc -vz smtp.domini.cat 587 ``` o instal·lar eines al host: ```bash root@peer-tube:~# apt install -y swaks openssl ``` ## 10. Prova STARTTLS port 587 Des de la VM: ```bash root@peer-tube:~# openssl s_client -starttls smtp -connect smtp.domini.cat:587 -crlf ``` Si funciona, veuràs negociació TLS i certificat. Això confirma que el port 587 espera STARTTLS, no TLS directe. ## 11. Prova SMTPS port 465 Des de la VM: ```bash root@peer-tube:~# openssl s_client -connect smtp.domini.cat:465 -crlf ``` Si funciona, el TLS comença directament. ## 12. Exemple amb `swaks` Per provar SMTP de manera clara: ```bash root@peer-tube:~# swaks \ --to correu-desti@example.net \ --from noreply@domini.cat \ --server smtp.domini.cat \ --port 587 \ --auth LOGIN \ --auth-user usuari@domini.cat \ --auth-password 'CONTRASENYA' \ --tls ``` Per port 465: ```bash root@peer-tube:~# swaks \ --to correu-desti@example.net \ --from noreply@domini.cat \ --server smtp.domini.cat \ --port 465 \ --auth LOGIN \ --auth-user usuari@domini.cat \ --auth-password 'CONTRASENYA' \ --tls-on-connect ``` ## 13. Checklist de coherència Per port 587: ```text PEERTUBE_SMTP_PORT=587 PEERTUBE_SMTP_TLS=false PEERTUBE_SMTP_DISABLE_STARTTLS=false ``` Per port 465: ```text PEERTUBE_SMTP_PORT=465 PEERTUBE_SMTP_TLS=true PEERTUBE_SMTP_DISABLE_STARTTLS=true ``` També comprovar: ```text usuari SMTP correcte password correcte FROM permès pel servidor SMTP domini del FROM coherent firewall sortint cap al port SMTP ``` ## 14. Punt important sobre `FROM` Molts servidors SMTP no deixen enviar com qualsevol remitent. Si autentiques com: ```text usuari@domini.cat ``` però poses: ```env PEERTUBE_SMTP_FROM=noreply@altresdomini.cat ``` pot fallar o enviar a spam. Millor començar amb: ```env PEERTUBE_SMTP_FROM=usuari@domini.cat ``` i després afinar. ## 15. Resum L’error actual apunta fortament a una combinació incorrecta de TLS: ```text TLS directe contra un port que espera SMTP normal + STARTTLS ``` La correcció més probable, si uses port 587, és: ```env PEERTUBE_SMTP_TLS=false PEERTUBE_SMTP_DISABLE_STARTTLS=false ``` Després: ```bash root@peer-tube:/opt/peertube# docker compose restart peertube ``` I tornar a provar el reset de contrasenya.