escolteu.me/BASE

Fork 0

Max HeadRoom bb7e08301c Upload files to "/"

2026-06-11 13:34:50 +02:00

223 KiB

Raw Permalink Blame History

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:

/var/lib/vz/template/iso/

Ens situem dins del directori:

cd /var/lib/vz/template/iso/

Descarreguem Ubuntu Server 24.04 LTS:

wget https://releases.ubuntu.com/24.04/ubuntu-24.04-live-server-amd64.iso

Comprovem que la ISO s’ha descarregat correctament:

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:

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

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:

192.168.100.101

2. Inici de l’assistent de creació

Des de la interfície web de Proxmox:

Datacenter → Node base → Create VM

En aquest cas el node Proxmox és:

base

3. Pestanya General

En aquesta pestanya definim el nom i l’identificador de la VM.

Valors recomanats

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:

peertube-vm

També podríem fer servir un nom més descriptiu:

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í:

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

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:

o un de nou, si el 1110 ja està ocupat.

Si volem comprovar des de terminal les màquines existents:

root@base:~# qm list

Això mostrarà les VMs existents i ens ajudarà a no repetir cap VM ID.

Exemple de sortida esperada:

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:

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:

root@base:/var/lib/vz/template/iso# ls -lh

Hauríem de veure el fitxer:

ubuntu-24.04-live-server-amd64.iso

Valors recomanats a la pestanya OS

A l’assistent de Proxmox seleccionem:

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

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:

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

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:

BIOS: OVMF (UEFI)

Això crea una VM moderna amb arrencada UEFI.

També cal marcar:

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:

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:

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:

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:

root@peertube-vm:~# apt install qemu-guest-agent

I l’activarem:

root@peertube-vm:~# systemctl enable --now qemu-guest-agent

Sobre TPM

Deixem TPM desactivat:

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

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:

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

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:

Disk size: 100 GB

També seria acceptable:

Disk size: 80 GB

Decisió presa

Assignem un disc d’aproximadament:

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:

TrueNAS 192.168.100.101

Bus del disc

Triem:

Bus/Device: SCSI

Això encaixa amb la decisió de la pestanya anterior:

SCSI Controller: VirtIO SCSI single

Storage del disc

Si el Proxmox té local-lvm, és una opció habitual per a discos de VM:

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:

Si el storage és directory: qcow2
Si el storage és local-lvm: raw / LVM-thin

Si Proxmox ofereix explícitament aquestes opcions:

RAW disk image
QEMU image / qcow2
VMware image / vmdk

La tria recomanada és:

QEMU image / qcow2

però si estem sobre local-lvm, és normal que Proxmox treballi amb volum LVM-thin i format tipus raw.

Cache

Deixem:

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:

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:

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:

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:

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

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ó

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:

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:

Async IO

Opció recomanada

Per a aquesta VM deixem:

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:

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:

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

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.

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

Sockets: 1
Cores: 4
Type: host
Enable NUMA: no
Extra CPU Flags: buit

Decisió presa

Assignem a la VM:

1 socket
4 cores
CPU type: host

Justificació

Fem servir:

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:

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:

Sockets: 1

No cal simular diversos sockets. Per a aquesta VM és millor una configuració senzilla:

1 socket x 4 cores

Sobre NUMA

Deixem:

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

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:

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:

Memory

Creació de la VM PeerTube

5. Correcció de la pestanya CPU

A la pestanya CPU faltava documentar el camp:

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:

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:

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:

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:

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:

CPU units: 512

Això faria que, en situació de càrrega, PeerTube tingués menys prioritat.

Important

No confondre:

Cores

amb:

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

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:

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

Memory: 8192 MiB
Minimum memory: buit / no ballooning
Ballooning Device: desactivat
Shares: per defecte

Decisió presa

Assignem a la VM:

Memory: 8192 MiB

És a dir:

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:

Ballooning Device: no

o, si la interfície mostra un camp de memòria mínima:

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:

Memory: 4096 MiB

Aquesta opció pot servir per a proves molt petites, però pot quedar justa.

Configuració recomanada:

Memory: 8192 MiB

Configuració més còmoda si hi ha recursos disponibles:

Memory: 12288 MiB

o bé:

Memory: 16384 MiB

Decisió final de memòria

Per començar triem:

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

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:

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

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:

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:

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:

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:

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:

Firewall: no

o bé:

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

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:

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:

80/tcp
443/tcp
53/udp
123/udp

I accés cap al TrueNAS per NFS:

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

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:

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:

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

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:

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:

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:

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:

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:

/
-
_
:
;
@

Això és important perquè aquesta VM es gestionarà molt per terminal i SSH.

Tipus d’instal·lació

L’instal·lador ofereix opcions semblants a:

Ubuntu Server
Ubuntu Server (minimal)

Per aquesta VM triem:

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:

Ubuntu Server

No seleccionem:

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ó:

Install third-party drivers

o equivalent en català:

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

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:

192.168.100.101

Per a la VM PeerTube assignem:

192.168.100.111

Decisió presa

La VM PeerTube tindrà IP fixa:

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:

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:

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:

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

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ó

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:

root@peertube-vm:~# ip a

root@peertube-vm:~# ip route

root@peertube-vm:~# ping -c 4 192.168.100.101

root@peertube-vm:~# ping -c 4 1.1.1.1

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:

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:

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:

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:

Set up this disk as an LVM group

o en català:

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:

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:

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í:

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:

100 GB

ens interessa que el volum principal / tingui una mida propera a:

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:

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

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

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:

root@peertube-vm:~# lsblk

root@peertube-vm:~# df -h

I si calgués revisar LVM:

root@peertube-vm:~# vgs

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:

VM PeerTube → Hardware → CD/DVD Drive → Edit

I hem deixat la unitat sense ISO muntada:

Do not use any media

o equivalent.

Per què cal treure la ISO?

Durant la instal·lació, la VM arrenca des de:

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ó:

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:

VM PeerTube → Options → Boot Order

L’ordre correcte hauria de prioritzar el disc de la VM:

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:

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:

xab

farem login amb aquest usuari.

Després, podem passar a root amb:

xab@peertube-vm:~$ sudo -i

El prompt passarà a ser:

root@peertube-vm:~#

Primeres comprovacions

Un cop dins la VM, comprovem que el sistema ha arrencat correctament.

Comprovar hostname

root@peertube-vm:~# hostname

Resultat esperat:

peertube-vm

Comprovar IP

root@peertube-vm:~# ip a

Hauríem de veure la IP configurada:

192.168.100.111

Comprovar ruta per defecte

root@peertube-vm:~# ip route

Hauríem de veure una ruta semblant a:

default via 192.168.100.1

Comprovar connexió amb TrueNAS

root@peertube-vm:~# ping -c 4 192.168.100.101

Si respon, la VM PeerTube veu correctament el TrueNAS.

Comprovar sortida a internet

root@peertube-vm:~# ping -c 4 1.1.1.1

Comprovar DNS

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.

root@peertube-vm:~# apt update

root@peertube-vm:~# apt upgrade -y

Instal·lació del Qemu Guest Agent

Com que a Proxmox hem activat l’opció:

Qemu Agent: enabled

ara instal·lem el servei dins d’Ubuntu.

root@peertube-vm:~# apt install -y qemu-guest-agent

L’activem i l’arranquem:

root@peertube-vm:~# systemctl enable --now qemu-guest-agent

Comprovem l’estat:

root@peertube-vm:~# systemctl status qemu-guest-agent

Instal·lació d’eines bàsiques

Instal·lem algunes eines útils per administrar la VM.

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.

root@peertube-vm:~# apt install -y nfs-common

Resum de la fase actual

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:

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:

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:

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.

xab@host-xab:~$ ls -lh ~/.ssh/

Normalment veurem fitxers semblants a:

id_ed25519
id_ed25519.pub
known_hosts

La clau pública és el fitxer acabat en .pub.

Per veure-la:

xab@host-xab:~$ cat ~/.ssh/id_ed25519.pub

La sortida serà una línia llarga semblant a:

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.

xab@host-xab:~$ ssh-keygen -t ed25519 -C "xab@host-xab"

Acceptem la ruta per defecte:

/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:

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:

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:

xab@peertube-vm:~$ sudo -i

Comprovem la carpeta .ssh de l’usuari:

root@peertube-vm:~# ls -ld /home/xab/.ssh

root@peertube-vm:~# ls -lh /home/xab/.ssh/authorized_keys

Els permisos correctes han de ser:

/home/xab/.ssh              700
/home/xab/.ssh/authorized_keys 600

Els deixem correctes explícitament:

root@peertube-vm:~# chown -R xab:xab /home/xab/.ssh

root@peertube-vm:~# chmod 700 /home/xab/.ssh

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:

xab@host-xab:~$ nano ~/.ssh/config

Afegim:

Host peertube-vm
    HostName 192.168.100.111
    User xab
    IdentityFile ~/.ssh/id_ed25519

Protegim el fitxer:

xab@host-xab:~$ chmod 600 ~/.ssh/config

Ara ja podem entrar amb:

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:

xab@host-xab:~$ ssh-copy-id root@IP_DEL_PROXMOX

Per exemple, si el Proxmox fos 192.168.100.10:

xab@host-xab:~$ ssh-copy-id root@192.168.100.10

Després provem:

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:

root@base:~# ls -ld /root/.ssh

root@base:~# ls -lh /root/.ssh/authorized_keys

Els permisos correctes són:

/root/.ssh                   700
/root/.ssh/authorized_keys   600

Els deixem correctes explícitament:

root@base:~# chown -R root:root /root/.ssh

root@base:~# chmod 700 /root/.ssh

root@base:~# chmod 600 /root/.ssh/authorized_keys

21. Crear un àlies SSH per al Proxmox

Al nostre ordinador local:

xab@host-xab:~$ nano ~/.ssh/config

Afegim també:

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:

xab@host-xab:~$ ssh proxmox-base

22. Fitxer SSH config complet d’exemple

El fitxer local podria quedar així:

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:

xab@host-xab:~$ ssh peertube-vm

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:

xab@host-xab:~$ cat ~/.ssh/id_ed25519.pub

Copiem tota la línia.

Després, a la VM PeerTube:

xab@peertube-vm:~$ mkdir -p ~/.ssh

xab@peertube-vm:~$ nano ~/.ssh/authorized_keys

Enganxem la clau pública en una sola línia.

Després ajustem permisos:

xab@peertube-vm:~$ chmod 700 ~/.ssh

xab@peertube-vm:~$ chmod 600 ~/.ssh/authorized_keys

En el cas de Proxmox, com a root:

root@base:~# mkdir -p /root/.ssh

root@base:~# nano /root/.ssh/authorized_keys

Enganxem la clau pública i ajustem permisos:

root@base:~# chmod 700 /root/.ssh

root@base:~# chmod 600 /root/.ssh/authorized_keys

root@base:~# chown -R root:root /root/.ssh

24. Comprovar que l’accés per clau funciona

Des del nostre ordinador local:

xab@host-xab:~$ ssh peertube-vm

I també:

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.

Primer fem una còpia del fitxer de configuració SSH.

root@peertube-vm:~# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Editem el fitxer:

root@peertube-vm:~# nano /etc/ssh/sshd_config

Busquem o afegim aquestes línies:

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:

xab@peertube-vm:~$ sudo -i

Comprovem la configuració abans de reiniciar el servei:

root@peertube-vm:~# sshd -t

Si no mostra cap error, reiniciem SSH:

root@peertube-vm:~# systemctl restart ssh

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:

root@base:~# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Editem:

root@base:~# nano /etc/ssh/sshd_config

Configurem:

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:

PermitRootLogin prohibit-password

Comprovem sintaxi:

root@base:~# sshd -t

Si no dona cap error:

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:

xab@host-xab:~$ ssh peertube-vm

I també:

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:

xab@host-xab:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no peertube-vm

Hauria de fallar.

També amb Proxmox:

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:

VM PeerTube: 192.168.100.111
Node Proxmox: base

Afegim àlies SSH locals:

peertube-vm
proxmox-base

Un cop validat l’accés per clau, desactivem l’autenticació per contrasenya.

29. Estat final esperat

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:

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:

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:

~/.ssh/id_ed25519

Això no és habitual ni recomanable.

El més normal és tenir:

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:

xab@host-xab:~$ ssh-keygen -lf ~/.ssh/id_ed25519.pub

Al Proxmox:

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:

256 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xab@host-xab (ED25519)

Què ha passat en el teu cas

Tu has fet:

local → proxmox

i funciona sense contrasenya.

També has fet:

proxmox → peer

i funciona, perquè el PeerTube té la clau pública del Proxmox.

Però amb ProxyJump fas:

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:

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:

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:

192.168.100.111

Disposem també d’un TrueNAS amb IP:

192.168.100.101

Al TrueNAS tenim preparada la ruta:

/mnt/AV/VM

L’objectiu és desplegar PeerTube amb Docker dins la VM Ubuntu, però separant clarament les dades:

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

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à:

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:

/opt/peertube/docker-volume/data -> /mnt/truenas-peertube/data

4. Preparació del TrueNAS

Al TrueNAS ja existeix:

root@truenas:~# ls -lna /mnt/AV/VM

Sortida actual:

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:

root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data

I una estructura inicial més llegible:

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.

root@truenas:~# chmod -R 775 /mnt/AV/VM/peertube

5. Export NFS des del TrueNAS

Des de la GUI de TrueNAS, exportem per NFS:

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:

/mnt/truenas-peertube

6. Preparació de la VM Ubuntu

Entrem a la VM PeerTube:

xab@host-xab:~$ ssh peertube-vm

Passem a root:

xab@peertube-vm:~$ sudo -i

Actualitzem el sistema:

root@peertube-vm:~# apt update
root@peertube-vm:~# apt upgrade -y

Instal·lem eines bàsiques:

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:

root@peertube-vm:~# install -m 0755 -d /etc/apt/keyrings

Descarreguem la clau oficial de Docker:

root@peertube-vm:~# curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

Assignem permisos:

root@peertube-vm:~# chmod a+r /etc/apt/keyrings/docker.asc

Afegim el repositori oficial:

root@peertube-vm:~# tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Actualitzem índexs:

root@peertube-vm:~# apt update

Instal·lem Docker, Buildx i Compose Plugin:

root@peertube-vm:~# apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Comprovem Docker:

root@peertube-vm:~# docker --version

Comprovem Docker Compose V2:

root@peertube-vm:~# docker compose version

Activem Docker a l’arrencada:

root@peertube-vm:~# systemctl enable --now docker

Comprovem estat:

root@peertube-vm:~# systemctl status docker

8. Prova del muntatge NFS contra TrueNAS

Creem el punt de muntatge:

root@peertube-vm:~# mkdir -p /mnt/truenas-peertube

Provem el muntatge manual:

root@peertube-vm:~# mount -t nfs4 192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube

Comprovem:

root@peertube-vm:~# df -h | grep truenas

També podem veure el contingut:

root@peertube-vm:~# ls -lna /mnt/truenas-peertube

Provem escriptura:

root@peertube-vm:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peer.txt

Comprovem:

root@peertube-vm:~# ls -lna /mnt/truenas-peertube

Si això funciona, el muntatge NFS és correcte.

9. Muntatge persistent amb /etc/fstab

Editem /etc/fstab:

root@peertube-vm:~# nano /etc/fstab

Afegim aquesta línia:

192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube nfs4 defaults,_netdev,nofail,x-systemd.automount 0 0

Desmuntem i provem el muntatge via fstab:

root@peertube-vm:~# umount /mnt/truenas-peertube

root@peertube-vm:~# systemctl daemon-reload

root@peertube-vm:~# mount -a

Comprovem:

root@peertube-vm:~# df -h | grep truenas

10. Creació del directori de desplegament de PeerTube

Creem el directori principal:

root@peertube-vm:~# mkdir -p /opt/peertube

Entrem:

root@peertube-vm:~# cd /opt/peertube

Descarreguem el docker-compose.yml oficial de producció:

root@peertube-vm:/opt/peertube# curl https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/docker-compose.yml > docker-compose.yml

Descarreguem el fitxer .env oficial de producció:

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:

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:

root@peertube-vm:/opt/peertube# mkdir -p docker-volume

Enllacem el directori de DATA gran cap al TrueNAS:

root@peertube-vm:/opt/peertube# ln -s /mnt/truenas-peertube/data docker-volume/data

Comprovem:

root@peertube-vm:/opt/peertube# ls -lna docker-volume

Hauríem de veure:

data -> /mnt/truenas-peertube/data
db
redis
config
opendkim

12. Adaptació del docker-compose.yml

El docker-compose.yml oficial porta serveis de:

webserver
certbot
webserver-reloader
peertube
postgres
redis
postfix

Nosaltres NO volem fer servir dins aquesta VM:

webserver
certbot
webserver-reloader

perquè el proxy invers i HTTPS els farà el CT Apache extern.

Per tant, editem el fitxer:

root@peertube-vm:/opt/peertube# nano docker-compose.yml

Cal comentar o eliminar aquests serveis:

webserver:
certbot:
webserver-reloader:

També cal modificar el servei peertube perquè publiqui el port intern 9000 cap a la VM:

ports:
  - "9000:9000"
  - "1935:1935"

Si no volem funcionalitat live RTMP, podem deixar comentat el port 1935.

Per a una primera prova, jo deixaria:

ports:
  - "9000:9000"

I si després volem directes:

ports:
  - "1935:1935"
  - "9000:9000"

13. Volums que han de quedar al compose

El servei peertube ha de mantenir:

volumes:
  - ./docker-volume/data:/data
  - ./docker-volume/config:/config

El servei postgres ha de mantenir:

volumes:
  - ./docker-volume/db:/var/lib/postgresql/data

El servei redis ha de mantenir:

volumes:
  - ./docker-volume/redis:/data

El servei postfix ha de mantenir:

volumes:
  - ./docker-volume/opendkim/keys:/etc/opendkim/keys

Això ens dona exactament la separació volguda:

/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:

root@peertube-vm:/opt/peertube# nano .env

Cal substituir els valors de plantilla:

<MY POSTGRES USERNAME>
<MY POSTGRES PASSWORD>
<MY DOMAIN>
<MY EMAIL ADDRESS>
<MY PEERTUBE SECRET>

La documentació oficial indica que aquests valors s’han de substituir al .env. :contentReference[oaicite:4]{index=4}

Exemple conceptual:

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:

root@peertube-vm:/opt/peertube# openssl rand -base64 32

Generem el secret de PeerTube:

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:

video.exemple.cat

Incorrecte:

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ò:

PEERTUBE_WEBSERVER_PORT=443
PEERTUBE_WEBSERVER_HTTPS=true

I el backend intern serà:

http://192.168.100.111:9000

17. Primera arrencada

Des de /opt/peertube:

root@peertube-vm:/opt/peertube# docker compose pull

Arrenquem:

root@peertube-vm:/opt/peertube# docker compose up -d

Mirem contenidors:

root@peertube-vm:/opt/peertube# docker compose ps

Mirem logs:

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:

root@peertube-vm:/opt/peertube# docker compose logs peertube | grep -A1 root

O per reiniciar-la manualment:

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:

root@peertube-vm:/opt/peertube# ss -lntp | grep 9000

Provem amb curl:

root@peertube-vm:/opt/peertube# curl -I http://127.0.0.1:9000

També des del Proxmox o des del CT Apache:

root@base:~# curl -I http://192.168.100.111:9000

20. Proxy invers Apache extern

Al CT Apache, el backend haurà d’apuntar a:

http://192.168.100.111:9000

El virtualhost públic farà:

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

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

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:

root@peertube-vm:/opt/peertube# docker compose ps

root@peertube-vm:/opt/peertube# curl -I http://127.0.0.1:9000

root@base:~# curl -I http://192.168.100.111:9000

root@peertube-vm:/opt/peertube# df -h | grep truenas

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à:

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:

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:

root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data

I després prepararem les subcarpetes de dades grans:

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:

root@truenas:~# find /mnt/AV/VM/peertube -maxdepth 3 -type d | sort

Resultat esperat:

/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:

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:

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:

/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:

root@truenas:~# mkdir -p /mnt/AV/VM/peertube/data

Creem les carpetes principals de dades:

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:

root@truenas:~# find /mnt/AV/VM/peertube -maxdepth 3 -type d | sort

Resultat esperat:

/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:

root@truenas:~# chmod -R 775 /mnt/AV/VM/peertube

Comprovem permisos i propietaris numèrics:

root@truenas:~# ls -lna /mnt/AV/VM

root@truenas:~# ls -lna /mnt/AV/VM/peertube

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:

Shares → Unix Shares (NFS) → Add

Configurem:

Path: /mnt/AV/VM/peertube
Description: PeerTube data for Ubuntu VM
Enabled: yes

Restricció recomanada:

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:

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:

System Settings → Services → NFS → Start Automatically
System Settings → Services → NFS → Start

L’estat esperat és:

NFS: RUNNING

9. Preparació de la VM Ubuntu

Entrem a la VM PeerTube:

xab@host-xab:~$ ssh peertube-vm

Passem a root:

xab@peertube-vm:~$ sudo -i

Actualitzem índexs de paquets:

root@peertube-vm:~# apt update

Instal·lem el client NFS:

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:

root@peertube-vm:~# mkdir -p /mnt/truenas-peertube

11. Prova de muntatge manual

Provem el muntatge NFS manualment:

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:

root@peertube-vm:~# df -h | grep truenas

També podem veure el contingut:

root@peertube-vm:~# ls -lna /mnt/truenas-peertube

I el directori de dades:

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:

root@peertube-vm:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt

Comprovem que existeix:

root@peertube-vm:~# ls -lna /mnt/truenas-peertube

També podem fer una prova dins la carpeta data:

root@peertube-vm:~# touch /mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt

Comprovem:

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:

root@truenas:~# ls -lna /mnt/AV/VM/peertube

root@truenas:~# ls -lna /mnt/AV/VM/peertube/data

Resultat esperat:

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:

mount.nfs: access denied by server while mounting

cal revisar a TrueNAS:

Allowed hosts
Path exportat
Servei NFS actiu
Permisos del dataset
Maproot User / Group

Si apareix un error de xarxa, comprovem connectivitat:

root@peertube-vm:~# ping -c 4 192.168.100.101

I comprovem si el port NFS respon:

root@peertube-vm:~# nc -vz 192.168.100.101 2049

Si no tenim nc, l’instal·lem:

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:

root@peertube-vm:~# nano /etc/fstab

Afegim aquesta línia al final:

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:

root@peertube-vm:~# umount /mnt/truenas-peertube

Recarreguem systemd:

root@peertube-vm:~# systemctl daemon-reload

Provem fstab:

root@peertube-vm:~# mount -a

Comprovem:

root@peertube-vm:~# df -h | grep truenas

I forcem accés al directori:

root@peertube-vm:~# ls -lna /mnt/truenas-peertube

18. Reinici de prova

Quan el muntatge persistent funcioni, podem reiniciar la VM:

root@peertube-vm:~# reboot

Després tornem a entrar:

xab@host-xab:~$ ssh peertube-vm

Passem a root:

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.

root@peertube-vm:~# ls -lna /mnt/truenas-peertube
root@peertube-vm:~# df -h | grep truenas

19. Decisió documentada

El directori del TrueNAS:

/mnt/AV/VM/peertube

queda muntat dins la VM Ubuntu com:

/mnt/truenas-peertube

Aquest muntatge serà la base per externalitzar la DATA gran de PeerTube.

20. Estat esperat al final d’aquesta fase

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:

root@peer-tube:~# df -h | grep truenas

Resultat:

192.168.100.101:/mnt/AV/VM/peertube   27G     0   27G   0% /mnt/truenas-peertube

També hi ha connectivitat IP correcta amb el TrueNAS:

root@peer-tube:~# ping -c 4 192.168.100.101

Resultat:

64 bytes from 192.168.100.101

Problema

Tot i que el recurs NFS està muntat, no es pot escriure:

root@peer-tube:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt

Error:

touch: cannot touch '/mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt': Permission denied

També falla dins de data:

root@peer-tube:~# touch /mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt

Error:

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:

root@peer-tube:~# ls -lna /mnt/truenas-peertube

Resultat:

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:

UID: 0
GID: 0

És a dir:

root:root

Però el root de la VM no pot escriure.

Això indica que el TrueNAS està aplicant una política de NFS tipus:

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:

nobody
nogroup

Això evita que qualsevol màquina client amb accés NFS pugui escriure com a root al NAS.

Per això passa això:

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:

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:

Shares → Unix Shares (NFS) → export /mnt/AV/VM/peertube

Cal deixar una configuració semblant a:

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:

Maproot User: root
Maproot Group: root

Després guardem els canvis i reiniciem o recarreguem el servei NFS si cal.

A TrueNAS:

System Settings → Services → NFS → Restart

Prova després de canviar Maproot

A la VM PeerTube, desmuntem i tornem a muntar:

root@peer-tube:~# umount /mnt/truenas-peertube

root@peer-tube:~# mount -t nfs4 192.168.100.101:/mnt/AV/VM/peertube /mnt/truenas-peertube

Provem escriptura:

root@peer-tube:~# touch /mnt/truenas-peertube/prova-escriptura-des-de-peertube-vm.txt

root@peer-tube:~# touch /mnt/truenas-peertube/data/prova-data-des-de-peertube-vm.txt

Comprovem:

root@peer-tube:~# ls -lna /mnt/truenas-peertube

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:

root@truenas:~# chmod -R 777 /mnt/AV/VM/peertube

Després, a la VM:

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:

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:

Maproot User: root
Maproot Group: root

Decisió provisional

Per aquesta fase del laboratori fem:

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:

VM Ubuntu → NFS → TrueNAS

Estat actual

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ó:

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:

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:

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:

root@peer-tube:~# df -h | grep truenas

Ara sí que hauria d’aparèixer el recurs muntat:

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:

root@peer-tube:~# ls -lna /mnt/truenas-peertube

root@peer-tube:~# df -h | grep truenas

root@peer-tube:~# touch /mnt/truenas-peertube/prova-post-reboot.txt

root@peer-tube:~# ls -lna /mnt/truenas-peertube

Decisió documentada

Mantenim l’opció:

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:

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:

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:

xab@host-xab:~$ ssh peertube-vm

Passem a root:

xab@peer-tube:~$ sudo -i

El prompt esperat és:

root@peer-tube:~#

3. Actualitzar el sistema

Actualitzem els índexs de paquets:

root@peer-tube:~# apt update

Actualitzem el sistema:

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:

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:

root@peer-tube:~# install -m 0755 -d /etc/apt/keyrings

6. Afegir la clau oficial de Docker

Descarreguem la clau GPG oficial de Docker:

root@peer-tube:~# curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

Assignem permisos de lectura:

root@peer-tube:~# chmod a+r /etc/apt/keyrings/docker.asc

7. Afegir el repositori oficial de Docker

Creem el fitxer del repositori Docker:

root@peer-tube:~# tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

8. Actualitzar índexs de paquets

Ara actualitzem de nou perquè Ubuntu vegi els paquets del repositori Docker:

root@peer-tube:~# apt update

9. Instal·lar Docker Engine i Docker Compose Plugin

Instal·lem Docker Engine, el client, containerd, Buildx i el plugin de Compose:

root@peer-tube:~# apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

10. Activar Docker a l’arrencada

Activem i arranquem Docker:

root@peer-tube:~# systemctl enable --now docker

Comprovem l’estat:

root@peer-tube:~# systemctl status docker

L’estat esperat és:

active (running)

11. Comprovar la versió de Docker

root@peer-tube:~# docker --version

Resultat esperat semblant a:

Docker version XX.X.X, build XXXXXXX

12. Comprovar Docker Compose V2

root@peer-tube:~# docker compose version

Resultat esperat semblant a:

Docker Compose version v2.xx.x

13. Prova bàsica de Docker

Executem el contenidor de prova:

root@peer-tube:~# docker run hello-world

Si tot és correcte, veurem un missatge semblant a:

Hello from Docker!

Això confirma que Docker pot descarregar imatges i executar contenidors.

14. Comprovació de xarxa Docker

Podem veure les xarxes creades per defecte:

root@peer-tube:~# docker network ls

Sortida esperada aproximada:

NETWORK ID     NAME      DRIVER    SCOPE
...            bridge    bridge    local
...            host      host      local
...            none      null      local

15. Comprovació de contenidors

Després del hello-world, podem veure els contenidors existents:

root@peer-tube:~# docker ps -a

El contenidor hello-world haurà quedat aturat.

Opcionalment, el podem eliminar:

root@peer-tube:~# docker rm $(docker ps -aq --filter ancestor=hello-world)

I també podem eliminar la imatge si volem deixar net:

root@peer-tube:~# docker rmi hello-world

16. Decisió documentada

Instal·lem Docker des del repositori oficial de Docker, no només des dels paquets base d’Ubuntu.

Això ens dona una versió actualitzada de:

Docker Engine
Docker CLI
containerd
Docker Buildx
Docker Compose Plugin

17. Estat esperat al final d’aquesta fase

Al final d’aquesta fase haurien de funcionar aquests comandos:

root@peer-tube:~# docker --version

root@peer-tube:~# docker compose version

root@peer-tube:~# systemctl status docker

root@peer-tube:~# docker run hello-world

18. Relació amb el projecte PeerTube

PeerTube es desplegarà amb Docker Compose.

La VM Ubuntu serà el host Docker, però les dades grans de PeerTube aniran al muntatge NFS del TrueNAS.

La separació continua sent:

VM Ubuntu:
  Docker
  PeerTube
  PostgreSQL
  Redis
  configuració
  logs
  volums interns petits

TrueNAS:
  vídeos originals
  transcodificats
  HLS
  thumbnails
  previews
  imports
  captions
  storyboards

19. Següent fase

Quan Docker funcioni correctament, passarem a preparar el directori de desplegament:

/opt/peertube

I descarregarem els fitxers oficials:

docker-compose.yml
.env

Després els adaptarem al nostre escenari:

sense webserver intern
sense certbot intern
sense webserver-reloader
amb /data apuntant al TrueNAS
amb PostgreSQL i Redis locals dins la VM
amb backend HTTP intern al port 9000

Desplegament de PeerTube: fase 3

1. Objectiu de la fase

Un cop Docker ja està instal·lat i validat, preparem el directori de desplegament de PeerTube.

En aquesta fase farem:

1. Crear /opt/peertube
2. Descarregar docker-compose.yml oficial
3. Descarregar .env oficial
4. Crear els directoris locals de Docker
5. Enllaçar la DATA gran cap al muntatge NFS del TrueNAS
6. Comprovar l’estructura abans d’arrencar res

2. Entrar a la VM PeerTube

Des de l’ordinador local:

xab@host-xab:~$ ssh peertube-vm

Passem a root:

xab@peer-tube:~$ sudo -i

El prompt esperat és:

root@peer-tube:~#

3. Comprovar que el muntatge NFS funciona

Com que fem servir x-systemd.automount, primer accedim al directori per activar el muntatge:

root@peer-tube:~# ls -lna /mnt/truenas-peertube

Ara comprovem que apareix muntat:

root@peer-tube:~# df -h | grep truenas

Resultat esperat:

192.168.100.101:/mnt/AV/VM/peertube   ...   /mnt/truenas-peertube

Comprovem la carpeta de dades:

root@peer-tube:~# ls -lna /mnt/truenas-peertube/data

4. Crear el directori principal de PeerTube

Creem el directori de desplegament:

root@peer-tube:~# mkdir -p /opt/peertube

Entrem dins:

root@peer-tube:~# cd /opt/peertube

El prompt passarà a ser:

root@peer-tube:/opt/peertube#

5. Descarregar els fitxers oficials de producció

Descarreguem el docker-compose.yml oficial:

root@peer-tube:/opt/peertube# curl https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/docker-compose.yml > docker-compose.yml

Descarreguem el fitxer .env oficial:

root@peer-tube:/opt/peertube# curl https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/.env > .env

Comprovem:

root@peer-tube:/opt/peertube# ls -lna

Resultat esperat:

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:

root@peer-tube:/opt/peertube# mkdir -p docker-volume

Creem els volums que volem mantenir locals dins de la VM:

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:

/mnt/truenas-peertube/data

Creem l’enllaç simbòlic:

root@peer-tube:/opt/peertube# ln -s /mnt/truenas-peertube/data docker-volume/data

8. Comprovar l’estructura resultant

Comprovem el directori docker-volume:

root@peer-tube:/opt/peertube# ls -lna docker-volume

Resultat esperat:

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:

root@peer-tube:/opt/peertube# ls -lna docker-volume/data

Això hauria de mostrar el contingut de:

/mnt/truenas-peertube/data

9. Prova d’escriptura des del camí final

Ara provem escriptura exactament pel camí que veurà Docker Compose:

root@peer-tube:/opt/peertube# touch docker-volume/data/prova-des-de-ruta-final-docker-volume.txt

Comprovem:

root@peer-tube:/opt/peertube# ls -lna docker-volume/data

També podem comprovar-ho des del camí NFS real:

root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube/data

10. Separació real de dades

Amb aquesta estructura, quan PeerTube escrigui a:

/data

dins del contenidor, realment escriurà a:

/opt/peertube/docker-volume/data

I aquest camí és un enllaç cap a:

/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:

/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:

PostgreSQL
Redis
configuració PeerTube
OpenDKIM
fitxers del desplegament

12. Què queda al TrueNAS

Al TrueNAS queda:

/mnt/AV/VM/peertube/data

Que la VM veu com:

/mnt/truenas-peertube/data

I Docker Compose veu com:

/opt/peertube/docker-volume/data

Aquest directori contindrà:

vídeos originals
vídeos transcodificats
HLS / streaming playlists
thumbnails
previews
imports
captions
storyboards
tmp

13. Esquema final de camins

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:

root@peer-tube:/opt/peertube# pwd

Resultat esperat:

/opt/peertube

Comprovem fitxers principals:

root@peer-tube:/opt/peertube# ls -lna

Comprovem volums:

root@peer-tube:/opt/peertube# ls -lna docker-volume

Comprovem muntatge:

root@peer-tube:/opt/peertube# df -h | grep truenas

Comprovem escriptura final:

root@peer-tube:/opt/peertube# touch docker-volume/data/prova-final.txt

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

/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:

docker-compose.yml
.env

Per adaptar-los al nostre escenari:

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:

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:

webserver
certbot
webserver-reloader

I fem que el servei peertube publiqui el port intern:

9000/tcp

2. Fer còpies de seguretat dels fitxers originals

Entrem al directori del desplegament:

root@peer-tube:~# cd /opt/peertube

Fem còpia del docker-compose.yml original:

root@peer-tube:/opt/peertube# cp docker-compose.yml docker-compose.yml.original

Fem còpia del .env original:

root@peer-tube:/opt/peertube# cp .env .env.original

Comprovem:

root@peer-tube:/opt/peertube# ls -lna

Resultat esperat:

.env
.env.original
docker-compose.yml
docker-compose.yml.original
docker-volume

3. Generar contrasenya de PostgreSQL

Generem una contrasenya llarga per PostgreSQL:

root@peer-tube:/opt/peertube# openssl rand -base64 32

Guardem el resultat per posar-lo al .env.

Exemple de valor:

CONTRASENYA_LLARGA_POSTGRES Nv47Om0bTtuSdEmCVyb10oGk2YDo9lcgkxj5Z+RzeIM=

4. Generar secret de PeerTube

Generem el secret de PeerTube:

root@peer-tube:/opt/peertube# openssl rand -hex 32

Guardem el resultat per posar-lo al .env.

Exemple de valor:

SECRET_LLARG_PEERTUBE 7938b6b369366e32647c9421f34840b23bd06b23a7bde08ce36151b70107daf6

5. Editar el fitxer .env

Obrim el fitxer .env:

root@peer-tube:/opt/peertube# nano .env

Hem de substituir els valors de plantilla pel nostre escenari.

Els valors principals són:

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:

video.exemple.cat

Incorrecte:

https://video.exemple.cat

Per tant:

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:

PEERTUBE_WEBSERVER_PORT=443
PEERTUBE_WEBSERVER_HTTPS=true

Això fa que PeerTube generi URLs públiques correctes amb:

https://DOMINI_TRIAT

8. Notes sobre TRUST_PROXY

Com que PeerTube estarà darrere d’un proxy invers Apache, cal confiar en el proxy.

Posem:

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:

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:

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.

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:

root@peer-tube:/opt/peertube# nano docker-compose.yml

Hem de modificar tres coses:

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:

webserver
certbot
webserver-reloader

El servei peertube exposarà directament el port intern 9000 a la VM Ubuntu:

192.168.100.111:9000

Aquest port serà consumit pel CT Apache Reverse Proxy.

Fitxer `docker-compose.yml`

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í:

root@peer-tube:/opt/peertube# cp docker-compose.yml docker-compose.yml.original

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:

root@peer-tube:/opt/peertube# docker compose config

Si no hi ha errors, mirem quins serveis detecta:

root@peer-tube:/opt/peertube# docker compose config --services

El resultat esperat és:

peertube
postgres
redis
postfix

No han d’aparèixer:

webserver
certbot
webserver-reloader

Decisió documentada

El docker-compose.yml queda adaptat per funcionar amb un proxy invers extern.

PeerTube queda exposat internament a:

http://192.168.100.111:9000

I el CT Apache serà qui publicarà el servei amb HTTPS cap a internet.

Separació de dades

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ó:

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:

root@peer-tube:/opt/peertube# docker compose config --services

Resultat esperat aproximat:

postgres
redis
postfix
peertube

No haurien d’aparèixer:

webserver
certbot
webserver-reloader

20. Primera descàrrega d’imatges

Quan la configuració sigui vàlida, descarreguem imatges:

root@peer-tube:/opt/peertube# docker compose pull

Això descarregarà:

PeerTube
PostgreSQL
Redis
Postfix

21. Primera arrencada

Arrenquem en segon pla:

root@peer-tube:/opt/peertube# docker compose up -d

22. Veure estat dels contenidors

root@peer-tube:/opt/peertube# docker compose ps

Resultat esperat:

postgres   running
redis      running
postfix    running
peertube   running

23. Veure logs de PeerTube

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:

root@peer-tube:/opt/peertube# docker compose up -d

els logs de PeerTube mostren aquest error:

TypeError: invalid range on address: 172.18.0.0/16, 192.168.100.104

Diagnosi

El problema és a la variable:

PEERTUBE_TRUST_PROXY

PeerTube està rebent aquesta part:

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:

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:

"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:

PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"]

Què representa cada entrada

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:

192.168.100.50

la línia hauria de ser:

PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.50"]

Correcció del fitxer .env

Editem el fitxer:

root@peer-tube:/opt/peertube# nano .env

Busquem:

PEERTUBE_TRUST_PROXY=

I deixem la línia així:

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:

root@peer-tube:/opt/peertube# docker compose down

Després tornem a aixecar:

root@peer-tube:/opt/peertube# docker compose up -d

Comprovar estat

root@peer-tube:/opt/peertube# docker compose ps

Consultar logs

root@peer-tube:/opt/peertube# docker compose logs -f peertube

Ja no hauria d’aparèixer:

invalid range on address

Comprovar la variable dins del contenidor

Podem comprovar què ha rebut realment el contenidor:

root@peer-tube:/opt/peertube# docker compose exec peertube printenv | grep PEERTUBE_TRUST_PROXY

El resultat esperat és:

PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"]

Validar el compose

També podem validar:

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:

X-Forwarded-For
X-Forwarded-Proto
Host

Sense aquesta configuració, PeerTube pot interpretar malament:

IP real del client
protocol públic HTTPS
domini públic

Resum

Valor corregit:

PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"]

Accions:

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

root@peer-tube:/opt/peertube# ss -lntp | grep 9000

Resultat esperat:

LISTEN ... :9000

25. Prova HTTP local

Des de la mateixa VM:

root@peer-tube:/opt/peertube# curl -I http://127.0.0.1:9000

Des del Proxmox:

root@base:~# curl -I http://192.168.100.111:9000

Des del CT Apache també hauria de respondre:

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:

root@peer-tube:/opt/peertube# docker compose logs peertube | grep -A1 root

Si cal reiniciar-la manualment:

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:

root@peer-tube:/opt/peertube# ls -lna docker-volume

Resultat esperat:

data -> /mnt/truenas-peertube/data

Comprovem el muntatge:

root@peer-tube:/opt/peertube# df -h | grep truenas

Si no surt, forcem l’automount:

root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube

I tornem a provar:

root@peer-tube:/opt/peertube# df -h | grep truenas

28. Decisió documentada

El desplegament de PeerTube queda adaptat així:

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:

CT Apache Reverse Proxy
  → http://192.168.100.111:9000

29. Estat esperat al final d’aquesta fase

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:

http://192.168.100.111:9000

I validar l’accés públic amb:

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

root@base:~# curl -I http://192.168.100.111:9000

Resultat:

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:

HTTP/1.1 200 OK

I confirma que el servei que respon és PeerTube:

x-powered-by: PeerTube

Diagnosi

PeerTube està funcionant internament a:

http://192.168.100.111:9000

Això confirma que:

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:

PEERTUBE_TRUST_PROXY

El valor havia de tenir cada element separat i amb les cometes correctes.

Exemple correcte:

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

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:

root@peer-tube:/opt/peertube# docker compose ps

Veure logs de PeerTube:

root@peer-tube:/opt/peertube# docker compose logs --tail=100 peertube

Comprovar que el muntatge TrueNAS continua actiu:

root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube

root@peer-tube:/opt/peertube# df -h | grep truenas

Comprovar que docker-volume/data apunta al TrueNAS:

root@peer-tube:/opt/peertube# ls -lna docker-volume

Resultat esperat:

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:

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:

https://DOMINI_TRIAT

cap al backend intern:

http://192.168.100.111:9000

El virtualhost Apache haurà de gestionar:

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:

Action 'graceful' failed

El log mostra:

(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:

AH00112: Warning: DocumentRoot [/home/rtd/public/m16] does not exist

2. Estat actual dels ports

Com a usuari normal s’ha executat:

rtd@Vhost:~$ ss -ltnp | grep ':80'

I mostra:

LISTEN 0      4096                 *:80               *:*

També:

rtd@Vhost:~$ ss -ltnp | grep ':443'

I mostra:

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:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

O bé, si encara estem com a rtd:

rtd@Vhost:~$ sudo ss -ltnp | grep -E ':80|:443'

El resultat hauria de mostrar el procés, per exemple:

users:(("apache2",pid=...,fd=...))

o bé:

users:(("nginx",pid=...,fd=...))

o bé:

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í:

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:

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

root@Vhost:~# systemctl status apache2

També:

root@Vhost:~# ps aux | grep apache2

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:

root@Vhost:~# apache2ctl configtest

El resultat correcte és:

Syntax OK

Si surt qualsevol altre error, cal corregir-lo abans de tornar a executar Certbot.

7. Localitzar el DocumentRoot inexistent

El warning és:

DocumentRoot [/home/rtd/public/m16] does not exist

Busquem quin VirtualHost el declara:

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:

root@Vhost:~# a2dissite NOM_DEL_SITE.conf

Si encara el volem mantenir, creem el directori:

root@Vhost:~# mkdir -p /home/rtd/public/m16

I opcionalment un index mínim:

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:

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:

root@Vhost:~# systemctl stop apache2

Comprovem si encara queda escoltant:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

Si encara apareixen processos apache2, els mirem:

root@Vhost:~# ps aux | grep apache2

I només si cal, matem processos Apache penjats:

root@Vhost:~# pkill apache2

Tornem a comprovar:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

Ara no hauria de sortir res ocupant 80/443.

Després netegem l’estat de systemd:

root@Vhost:~# systemctl reset-failed apache2

Validem configuració:

root@Vhost:~# apache2ctl configtest

I arrenquem Apache:

root@Vhost:~# systemctl start apache2

Comprovem:

root@Vhost:~# systemctl status apache2

I ports:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

Ara haurien de sortir ocupats per Apache, però amb el servei en estat correcte:

active (running)

9. Si els ports els ocupa un altre servei

Si ss mostra nginx:

root@Vhost:~# systemctl status nginx

Si no el necessitem:

root@Vhost:~# systemctl stop nginx

root@Vhost:~# systemctl disable nginx

Si mostra docker-proxy:

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:

root@Vhost:~# apache2ctl configtest

root@Vhost:~# systemctl restart apache2

root@Vhost:~# systemctl status apache2

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:

root@Vhost:~# curl -I http://DOMINI_TRIAT

També provem el backend PeerTube:

root@Vhost:~# curl -I http://192.168.100.111:9000

El backend PeerTube hauria de respondre:

HTTP/1.1 200 OK
x-powered-by: PeerTube

12. Tornar a executar Certbot

Només quan Apache estigui en estat correcte:

apache2ctl configtest → Syntax OK
systemctl status apache2 → active (running)
curl http://DOMINI_TRIAT → respon

tornem a Certbot:

root@Vhost:~# certbot --apache -d DOMINI_TRIAT

13. Comandes immediates recomanades

Ara mateix executaria aquest bloc:

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:

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:

root@Vhost:~# ss -ltnp | grep ':80'

Resultat:

LISTEN 0 4096 *:80 *:* users:(("caddy",pid=1311928,fd=8))

I també:

root@Vhost:~# ss -ltnp | grep ':443'

Resultat:

LISTEN 0 4096 *:443 *:* users:(("caddy",pid=1311928,fd=6))

Per tant, el procés que ocupa els ports públics és:

caddy

Ara cal saber:

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:

root@Vhost:~# systemctl status caddy

Aquesta ordre ens dirà:

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:

Loaded: loaded (...; enabled; ...)
Active: active (running) since ...
Main PID: 1311928 (caddy)

Si diu:

enabled

vol dir que Caddy està configurat per arrencar automàticament amb la màquina.

3. Veure si Caddy està habilitat al boot

root@Vhost:~# systemctl is-enabled caddy

Resultats possibles:

enabled

Vol dir que Caddy arrenca automàticament.

disabled

Vol dir que no hauria d’arrencar sol amb el boot, però algú l’ha pogut iniciar manualment.

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:

root@Vhost:~# ps -fp 1311928

I també:

root@Vhost:~# pstree -sp 1311928

Resultat esperat si l’ha arrencat systemd:

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

root@Vhost:~# systemctl cat caddy

Això mostrarà el fitxer de servei, normalment alguna cosa com:

/etc/systemd/system/caddy.service

/lib/systemd/system/caddy.service

Cal mirar sobretot:

ExecStart=
ExecReload=
User=
Group=

Això ens dirà com s’està arrencant Caddy.

6. Veure quan s’ha arrencat Caddy

Mirem el journal del servei:

root@Vhost:~# journalctl -u caddy -n 100 --no-pager

Per veure només el boot actual:

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:

Started caddy.service - Caddy.

systemd[1]: Starting caddy.service

7. Comparar amb l’arrencada del sistema

Mirem quan ha arrencat el CT o la màquina:

root@Vhost:~# uptime -s

I comparem-ho amb:

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:

root@Vhost:~# journalctl -b --no-pager | grep -i caddy

També podem mirar reinicis anteriors:

root@Vhost:~# journalctl --list-boots

Això mostrarà una llista de boots.

Exemple:

-1  boot anterior
 0  boot actual

Podem mirar Caddy al boot anterior:

root@Vhost:~# journalctl -u caddy -b -1 --no-pager

I al boot actual:

root@Vhost:~# journalctl -u caddy -b 0 --no-pager

9. Veure si algun timer o procés ha tocat Caddy

Llistem timers actius:

root@Vhost:~# systemctl list-timers --all

Busquem coses relacionades amb Caddy o renovació de certificats:

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

root@Vhost:~# dpkg -l | grep caddy

També podem mirar quan es va instal·lar:

root@Vhost:~# grep -i caddy /var/log/apt/history.log

Si els logs estan rotats:

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

root@Vhost:~# ls -lna /etc/caddy

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:

root@Vhost:~# grep -R "reverse_proxy\|:80\|:443\|tls\|http://" /etc/caddy /etc/systemd/system /lib/systemd/system 2>/dev/null

Això pot mostrar:

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:

root@Vhost:~# systemctl is-enabled apache2

root@Vhost:~# systemctl status apache2

Si tots dos estan habilitats:

caddy enabled
apache2 enabled

llavors al boot poden competir pels ports 80/443.

14. Diagnosi probable

Si systemctl status caddy mostra:

Loaded: loaded (...; enabled; ...)
Active: active (running) since ...

aleshores la resposta és:

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

root@Vhost:~# systemctl status caddy

root@Vhost:~# systemctl is-enabled caddy

root@Vhost:~# pstree -sp 1311928

root@Vhost:~# journalctl -u caddy -b --no-pager

root@Vhost:~# cat /etc/caddy/Caddyfile

root@Vhost:~# systemctl is-enabled apache2

16. Possibles conclusions

Cas A: Caddy està enabled

Conclusió:

Caddy arrenca automàticament al boot.

Si volem fer servir Apache, caldrà desactivar Caddy:

root@Vhost:~# systemctl disable --now caddy

Després:

root@Vhost:~# systemctl restart apache2

Cas B: Caddy està disabled però actiu

Conclusió:

Algú l’ha iniciat manualment o algun altre servei l’ha cridat.

Caldrà mirar:

root@Vhost:~# journalctl -u caddy -b --no-pager

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:

root@Vhost:~# ps aux | grep caddy

root@Vhost:~# readlink -f /proc/1311928/exe

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:

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í:

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:

http://192.168.100.111:9000

Apache fa de frontal públic:

https://DOMINI_PEERTUBE

2. Comprovació prèvia del backend PeerTube

Des del CT Vhost:

root@Vhost:~# curl -I http://192.168.100.111:9000

Resultat esperat:

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:

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:

root@Vhost:~# a2enmod http2

Comprovem sintaxi:

root@Vhost:~# apache2ctl configtest

Resultat esperat:

Syntax OK

Recarreguem Apache:

root@Vhost:~# systemctl reload apache2

4. VirtualHost HTTP inicial

Abans de Certbot, podem crear un VirtualHost HTTP senzill.

Fitxer:

/etc/apache2/sites-available/peertube.conf

Crear-lo:

root@Vhost:~# nano /etc/apache2/sites-available/peertube.conf

Contingut inicial:

<VirtualHost *:80>
    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
</VirtualHost>

Activem el site:

root@Vhost:~# a2ensite peertube.conf

Comprovem:

root@Vhost:~# apache2ctl configtest

Recarreguem:

root@Vhost:~# systemctl reload apache2

Prova HTTP:

root@Vhost:~# curl -I http://DOMINI_PEERTUBE

Resultat esperat:

HTTP/1.1 200 OK
x-powered-by: PeerTube

5. Certificat TLS amb Certbot

Quan HTTP ja funciona, demanem el certificat:

root@Vhost:~# certbot --apache -d DOMINI_PEERTUBE

Certbot crearà o modificarà el VirtualHost SSL.

Després comprovem:

root@Vhost:~# apache2ctl configtest

root@Vhost:~# systemctl reload apache2

Prova HTTPS:

root@Vhost:~# curl -I https://DOMINI_PEERTUBE

6. VirtualHost HTTPS recomanat

Després de Certbot, el fitxer pot quedar repartit entre:

/etc/apache2/sites-available/peertube.conf
/etc/apache2/sites-available/peertube-le-ssl.conf

La part HTTPS hauria de quedar semblant a això:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

7. Redirecció HTTP cap a HTTPS

El VirtualHost de port 80 pot quedar només com a redirecció:

<VirtualHost *:80>
    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
</VirtualHost>

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:

root@Vhost:~# a2enmod proxy_wstunnel

Una versió amb detecció d’upgrade seria:

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:

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:

LimitRequestBody 0

Això vol dir que Apache no imposa un límit propi de mida.

També és útil tenir timeouts llargs:

ProxyTimeout 600
Timeout 600

Si es preveuen pujades molt lentes o fitxers molt grossos, podem pujar-ho a:

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:

/opt/peertube/.env

Valors importants:

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:

192.168.100.104

la línia hauria de ser:

PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"]

Després de canviar el .env:

root@peer-tube:/opt/peertube# docker compose down
root@peer-tube:/opt/peertube# docker compose up -d

O, si volem fer només restart:

root@peer-tube:/opt/peertube# docker compose restart peertube

11. Fitxer Apache final compacte

Fitxer recomanat:

/etc/apache2/sites-available/peertube.conf

Contingut complet:

<VirtualHost *:80>
    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
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

12. Activació final

root@Vhost:~# a2enmod proxy proxy_http proxy_wstunnel headers ssl rewrite http2

root@Vhost:~# a2ensite peertube.conf

root@Vhost:~# apache2ctl configtest

Resultat esperat:

Syntax OK

root@Vhost:~# systemctl reload apache2

13. Proves finals

Des del CT Vhost:

root@Vhost:~# curl -I http://192.168.100.111:9000

root@Vhost:~# curl -I https://DOMINI_PEERTUBE

Des de fora:

curl -I https://DOMINI_PEERTUBE

Resultat esperat:

HTTP/2 200
x-powered-by: PeerTube

O bé:

HTTP/1.1 200 OK
x-powered-by: PeerTube

segons si HTTP/2 queda actiu.

14. Logs útils

Apache:

root@Vhost:~# tail -f /var/log/apache2/peertube-ssl-error.log

root@Vhost:~# tail -f /var/log/apache2/peertube-ssl-access.log

PeerTube:

root@peer-tube:/opt/peertube# docker compose logs -f peertube

15. Renovació de certificat

Certbot instal·la normalment renovació automàtica.

Comprovació:

root@Vhost:~# systemctl list-timers | grep certbot

Prova de renovació:

root@Vhost:~# certbot renew --dry-run

16. Estat final esperat

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:

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:

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:

users:(("caddy",pid=...,fd=...))

Diagnosi real

La comprovació amb systemctl va mostrar que no hi havia cap servei caddy.service instal·lat al sistema:

systemctl status caddy

retornava:

Unit caddy.service could not be found.

Però l’arbre de processos mostrava:

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:

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:

Apache + Certbot
Docker/Caddy/Snikket

Tots dos volien fer servir els mateixos ports públics:

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:

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:

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é:

/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:

root@Vhost:~# grep -R "letsencrypt" /etc/apache2/sites-available /etc/apache2/sites-enabled

Per veure quins certificats coneix Certbot:

root@Vhost:~# certbot certificates

Per eliminar correctament un certificat:

root@Vhost:~# certbot delete --cert-name NOM_CERTIFICAT

Per validar Apache després de qualsevol canvi:

root@Vhost:~# apache2ctl configtest

Resultat esperat:

Syntax OK

I després:

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:

Internet
   |
   | HTTPS 443
   v
Apache + Certbot al CT Vhost
   |
   | HTTP intern
   v
PeerTube VM
192.168.100.111:9000

I PeerTube queda publicat amb:

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:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

root@Vhost:~# docker ps

root@Vhost:~# systemctl status apache2

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:

/etc/apache2/sites-available/vm.domini.cat.conf

Amb un VirtualHost HTTP:

<VirtualHost *:80>
    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
</VirtualHost>

Quan executes:

root@Vhost:~# certbot --apache -d vm.domini.cat

Certbot fa diverses coses:

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:

/etc/apache2/sites-available/vm.domini.cat-le-ssl.conf

Aquest fitxer sol contenir el VirtualHost HTTPS:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

Per tant, sí: el -le-ssl.conf complementa el .conf original.

Normalment queda així:

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ò:

<VirtualHost *:80>
    ServerName vm.domini.cat
    ...
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName vm.domini.cat
    ...
</VirtualHost>
</IfModule>

Certbot pot fer una de dues coses:

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:

vm.domini.cat.conf
    → <VirtualHost *:443>
    → ServerName vm.domini.cat

vm.domini.cat-le-ssl.conf
    → <VirtualHost *:443>
    → 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:

Include /etc/letsencrypt/options-ssl-apache.conf

inclou paràmetres SSL recomanats per Certbot.

Normalment defineix coses com:

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:

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:

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:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

Aquí falta el certificat:

SSLCertificateFile ...
SSLCertificateKeyFile ...

O bé hi són, però apunten a un certificat esborrat.

6. Com mirar què veu Apache realment

La comanda clau és:

root@Vhost:~# apache2ctl -S

Això et diu:

quins VirtualHosts hi ha
quin fitxer els defineix
quin és el default de cada port
si tens duplicats

Per exemple:

*: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:

*: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:

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:

/etc/apache2/sites-available/vm.domini.cat.conf

i desactivar/eliminar el -le-ssl.conf si ja no el vols:

root@Vhost:~# a2dissite vm.domini.cat-le-ssl.conf

Després:

root@Vhost:~# apache2ctl configtest
root@Vhost:~# systemctl reload apache2

8. El socket: què està passant realment

Quan diem:

ProxyPass / http://192.168.100.111:9000/

Apache fa de client HTTP contra PeerTube.

L’esquema real és:

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:

192.168.100.111:9000

Això és el socket:

IP origen: CT Vhost
IP destí: 192.168.100.111
Port destí: 9000
Protocol: TCP
Aplicació: HTTP

9. ProxyPass i ProxyPassReverse

Això:

ProxyPass / http://192.168.100.111:9000/

vol dir:

tot el que arribi a https://vm.domini.cat/
envia-ho internament a http://192.168.100.111:9000/

Això:

ProxyPassReverse / http://192.168.100.111:9000/

serveix perquè si el backend respon amb capçaleres de redirecció, Apache les corregeixi.

Exemple:

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:

RequestHeader set X-Forwarded-Proto "https"

PeerTube per dins rep HTTP, perquè Apache li parla per:

http://192.168.100.111:9000

Però l’usuari real està entrant per:

https://vm.domini.cat

Per tant, Apache ha d’avisar PeerTube:

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:

http://vm.domini.cat

en comptes de:

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:

RequestHeader append X-Forwarded-For "%{REMOTE_ADDR}s"

o amb configuració equivalent, PeerTube pot saber millor d’on venen les peticions.

També és habitual:

RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"

12. Timeouts

Aquests paràmetres:

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:

pujada de vídeos grans
processament
importacions
connexions llargues
respostes lentes del backend

Si el timeout és massa curt, pots veure errors tipus:

504 Gateway Timeout
proxy timeout
connection reset

Valors raonables:

ProxyTimeout 600
Timeout 600

Per pujades molt grosses o línies lentes:

ProxyTimeout 1800
Timeout 1800

13. Límit de mida de pujada

Això:

LimitRequestBody 0

vol dir:

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:

root@Vhost:~# a2enmod proxy_wstunnel

I es pot configurar així:

RewriteEngine On

RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule /(.*) ws://192.168.100.111:9000/$1 [P,L]

Això diu:

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:

<VirtualHost *:80>
    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
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

16. Ordre mental correcta

Jo ho pensaria així:

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:

root@Vhost:~# certbot certificates

Per veure si Apache té duplicats:

root@Vhost:~# apache2ctl -S

Per veure referències a Let’s Encrypt:

root@Vhost:~# grep -R "letsencrypt" /etc/apache2/sites-available /etc/apache2/sites-enabled

Per validar abans de recarregar:

root@Vhost:~# apache2ctl configtest

Per veure qui ocupa ports:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

18. Conclusió curta

La teva idea és correcta:

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:

apache2ctl -S

i netejar línies velles de:

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:

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:

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:

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:

Include /etc/letsencrypt/options-ssl-apache.conf

i, en alguns casos, referències a certificats:

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:

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:

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:

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:

/etc/apache2/sites-available/vm.domini.cat.conf

amb un bloc HTTP:

<VirtualHost *:80>
    ServerName vm.domini.cat
    ...
</VirtualHost>

i executem:

root@Vhost:~# certbot --apache -d vm.domini.cat

Certbot busca un VirtualHost que coincideixi amb:

ServerName vm.domini.cat

Si troba un bloc *:80, però no troba un bloc SSL clar, normalment crea un fitxer nou:

/etc/apache2/sites-available/vm.domini.cat-le-ssl.conf

Aquest fitxer conté el VirtualHost HTTPS:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

Això vol dir que, per defecte, Certbot pot deixar l’estructura així:

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:

/etc/apache2/sites-available/vm.domini.cat.conf

amb aquesta estructura:

<VirtualHost *:80>
    ...
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ...
</VirtualHost>
</IfModule>

El bloc *:80 només redirigeix a HTTPS.

El bloc *:443 és el reverse proxy real cap a PeerTube.

5. Configuració Apache consolidada

Fitxer:

/etc/apache2/sites-available/vm.domini.cat.conf

Contingut recomanat:

<VirtualHost *:80>
    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
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    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
</VirtualHost>
</IfModule>

6. Correccions aplicades respecte al bloc inicial

6.1. Eliminar `ProxyPass` duplicat

No convé tenir això dues vegades:

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:

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:

RequestHeader set X-Forwarded-Host ""

Això pot confondre el backend.

Millor:

RequestHeader set X-Forwarded-Host "%{HTTP_HOST}s"

O, en alguns escenaris, simplement es podria eliminar perquè:

ProxyPreserveHost On

ja conserva la capçalera Host.

Però si volem deixar-ho explícit:

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:

ErrorLog ${APACHE_LOG_DIR}/peertubeVM_80_error.log
CustomLog ${APACHE_LOG_DIR}/peertubeVM_80_access.log combined

ErrorLog ${APACHE_LOG_DIR}/peertubeVM_443_error.log
CustomLog ${APACHE_LOG_DIR}/peertubeVM_443_access.log combined

Això ajuda a distingir:

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:

root@Vhost:~# apache2ctl -S

Ens interessa detectar si hi ha dos fitxers actius per al mateix domini:

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:

root@Vhost:~# a2dissite vm.domini.cat-le-ssl.conf

Ens assegurem que el fitxer principal està actiu:

root@Vhost:~# a2ensite vm.domini.cat.conf

Activem els mòduls necessaris:

root@Vhost:~# a2enmod proxy proxy_http proxy_wstunnel headers ssl rewrite http2

Validem configuració:

root@Vhost:~# apache2ctl configtest

Resultat esperat:

Syntax OK

Recarreguem Apache:

root@Vhost:~# systemctl reload apache2

8. Comprovar que no queda duplicació

Després del canvi:

root@Vhost:~# apache2ctl -S

El resultat bo hauria de ser semblant a:

*: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:

vm.domini.cat-le-ssl.conf

Si apareix, encara està activat o hi ha un enllaç dins:

/etc/apache2/sites-enabled/

Es pot revisar amb:

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:

root@Vhost:~# grep -R "letsencrypt" /etc/apache2/sites-enabled/

Per veure referències a certificats:

root@Vhost:~# grep -R "SSLCertificate" /etc/apache2/sites-enabled/

Per veure qualsevol referència al domini:

root@Vhost:~# grep -R "vm.domini.cat" /etc/apache2/sites-enabled/

També és útil mirar tant sites-available com sites-enabled:

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:

root@Vhost:~# certbot certificates

Si el certificat existeix, hauríem de veure alguna cosa semblant a:

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:

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:

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:

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:

vm.domini.cat-le-ssl.conf

Si l’ha creat, pots tornar a consolidar:

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:

root@Vhost:~# certbot certonly --apache -d vm.domini.cat

Després poses manualment les línies:

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:

ProxyPass / http://192.168.100.111:9000/ retry=0 timeout=600

diu a Apache:

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:

ProxyPassReverse / http://192.168.100.111:9000/

serveix per corregir redireccions del backend.

Per exemple, si PeerTube respongués:

Location: http://192.168.100.111:9000/login

Apache pot transformar-ho en:

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:

http://192.168.100.111:9000

Però l’usuari real entra per HTTPS:

https://vm.domini.cat

Per això Apache ha d’informar PeerTube de la situació real.

`X-Forwarded-Proto`

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`

RequestHeader set X-Forwarded-Port "443"

Indica que el port públic era el 443.

`X-Forwarded-Host`

RequestHeader set X-Forwarded-Host "%{HTTP_HOST}s"

Indica quin host havia demanat el client.

Per exemple:

vm.domini.cat

`X-Forwarded-For`

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`

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:

ProxyTimeout 600
Timeout 600

donen més marge a Apache per esperar respostes del backend.

PeerTube pot tenir operacions llargues:

pujada de vídeos
importació remota
transcodificació
respostes lentes
connexions persistents

Amb timeouts massa curts poden aparèixer errors:

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:

ProxyTimeout 1800
Timeout 1800

16. Explicació de `LimitRequestBody`

Aquesta línia:

LimitRequestBody 0

vol dir:

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:

PeerTube
Node.js
Docker
disc
NFS
configuració interna de la instància

17. Explicació de WebSocket

Aquest bloc:

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:

Upgrade: websocket
Connection: upgrade

Quan Apache detecta això, envia la connexió al backend amb:

ws://192.168.100.111:9000/

Per això cal el mòdul:

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:

/opt/peertube/.env

ha de ser coherent amb el domini públic.

Valors importants:

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:

192.168.100.104

llavors:

PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "172.18.0.0/16", "192.168.100.104"]

Després de canviar .env:

root@peer-tube:/opt/peertube# docker compose down
root@peer-tube:/opt/peertube# docker compose up -d

O bé:

root@peer-tube:/opt/peertube# docker compose restart peertube

19. Proves del backend PeerTube

Des del CT Vhost:

root@Vhost:~# curl -I http://192.168.100.111:9000

Resultat esperat:

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:

root@Vhost:~# curl -I http://vm.domini.cat

Resultat esperat:

HTTP/1.1 301 Moved Permanently
Location: https://vm.domini.cat/

Prova HTTPS:

root@Vhost:~# curl -I https://vm.domini.cat

Resultat esperat:

HTTP/2 200

HTTP/1.1 200 OK

i idealment alguna capçalera com:

x-powered-by: PeerTube

21. Comprovació de ports

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

Resultat esperat:

apache2

No hauria de sortir:

caddy
docker-proxy
nginx

22. Logs útils

Logs Apache del port 80:

root@Vhost:~# tail -f /var/log/apache2/peertubeVM_80_error.log

root@Vhost:~# tail -f /var/log/apache2/peertubeVM_80_access.log

Logs Apache del port 443:

root@Vhost:~# tail -f /var/log/apache2/peertubeVM_443_error.log

root@Vhost:~# tail -f /var/log/apache2/peertubeVM_443_access.log

Logs PeerTube:

root@peer-tube:/opt/peertube# docker compose logs -f peertube

23. Renovació del certificat

Comprovem timers de Certbot:

root@Vhost:~# systemctl list-timers | grep certbot

Prova de renovació:

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:

/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

root@Vhost:~# apache2ctl -S

Ha de mostrar només:

*:80   vm.domini.cat (...vm.domini.cat.conf...)
*:443  vm.domini.cat (...vm.domini.cat.conf...)

Validació:

root@Vhost:~# apache2ctl configtest

Resultat:

Syntax OK

Ports:

root@Vhost:~# ss -ltnp | grep -E ':80|:443'

Ha de sortir:

apache2

Certificat:

root@Vhost:~# certbot certificates

Ha d’existir:

vm.domini.cat

Backend:

root@Vhost:~# curl -I http://192.168.100.111:9000

Domini públic:

root@Vhost:~# curl -I https://vm.domini.cat

Docker antic:

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í:

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:

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:

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:

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:

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:

/mnt/AV/VM/peertube

i especialment a:

/mnt/AV/VM/peertube/data

A la VM PeerTube aquest dataset entra com:

/mnt/truenas-peertube

i després PeerTube l’usa mitjançant:

/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:

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:

root@peer-tube:~# touch /mnt/truenas-peertube/data/prova-root-vm.txt

Prova d’escriptura des del contenidor PeerTube:

root@peer-tube:/opt/peertube# docker compose exec peertube sh

Dins del contenidor:

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:

root@truenas:~# chown -R UID:GID /mnt/AV/VM/peertube/data

o bé, si volem una solució més permissiva de laboratori:

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:

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:

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:

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:

root@peer-tube:/opt/peertube# grep -i smtp .env

Logs després de modificar SMTP:

root@peer-tube:/opt/peertube# docker compose logs -f peertube

Reinici del servei:

root@peer-tube:/opt/peertube# docker compose restart peertube

Prova funcional

Des de la interfície web:

Administration → Configuration → Email / SMTP

o prova de registre / recuperació de contrasenya.

També podem mirar si el contenidor intenta connectar:

root@peer-tube:/opt/peertube# docker compose exec peertube sh

i dins:

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:

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:

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:

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:

domini antic
estat
accés admin
volum de vídeos
versió PeerTube

A la nova:

domini nou
estat admin
versió PeerTube
configuració federation enabled

A la nova instància cal comprovar:

Administration → Configuration → Federation

i confirmar que la federació està activa.

Proves mínimes

Des de la nova instància:

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ó:

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:

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:

Administration → Configuration → Import

Cal buscar opcions com:

enable video import
enable import via URL
allow users to import videos

A nivell contenidor:

root@peer-tube:/opt/peertube# docker compose exec peertube sh

Dins:

which youtube-dl
which yt-dlp
yt-dlp --version
youtube-dl --version

Decisió

Hi ha dues formes:

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:

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:

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:

VM Ubuntu PeerTube
Docker Compose
NFS TrueNAS
Apache Vhost
Certbot/TLS
reverse proxy funcional

Fase 2 — Permisos i persistència

Pendent immediat:

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:

decidir SMTP final
configurar .env
reiniciar PeerTube
provar enviament
verificar logs

Fase 4 — Federació i migració

Pendent:

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:

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:

firewall bàsic
només ports necessaris oberts
backups
rotació de logs
monitoratge d’espai NFS
actualitzacions controlades

Fase 7 — Documentació final

Pendent:

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:

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:

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:

root@peer-tube:/opt/peertube# docker compose exec peertube id

També:

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:

root@peer-tube:/opt/peertube# ls -lna /mnt/truenas-peertube/data

I al TrueNAS:

root@truenas:~# ls -lna /mnt/AV/VM/peertube/data

Amb això sabrem:

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:

root@peer-tube:/opt/peertube# grep -i smtp .env

I després decidim si usem:

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:

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:

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:

/mnt/AV/VM/peertube/data

Aquest directori es va crear manualment des del TrueNAS com a root, per tant inicialment tenia propietat:

0:0

És a dir:

UID 0 → root
GID 0 → root

En fase de laboratori es van aplicar permisos amplis:

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:

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:

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:

999:999

Per exemple:

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:

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:

/etc/passwd
/etc/group

Per tant, el mateix número pot tenir noms diferents segons el sistema.

Per exemple:

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:

ls -lna

En comptes de:

ls -la

La dada fiable és:

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:

docker compose exec peertube sh

I dins del contenidor:

id

va retornar:

uid=0(root) gid=0(root)

Quan es va crear un fitxer manualment:

touch /data/prova-des-del-contenidor.txt

aquest fitxer va aparèixer com:

0:0

Això demostra que si escriu root, arriba root.

Per tant:

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:

chown -R 999:999 /mnt/AV/VM/peertube/data

Això vol dir:

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:

chown -R 999:999 /mnt/AV/VM/peertube/data

Respon a la pregunta:

de qui són aquests fitxers?

`chmod`

Canvia els permisos:

chmod 2750 directori
chmod 640 fitxer

Respon a la pregunta:

què pot fer el propietari, el grup i la resta d’usuaris?

Per tant, el refinament té dues parts:

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:

Que volen dir:

7 → propietari
7 → grup
5 → altres

Cada xifra és la suma de:

4 → read / lectura
2 → write / escriptura
1 → execute / execució o entrada en directori

Per tant:

7 = 4+2+1 = read + write + execute
5 = 4+1   = read + execute

Un directori amb 775 queda així:

drwxrwxr-x

Això vol dir:

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:

Aquest primer dígit activa permisos especials.

Els valors són:

4 → setuid
2 → setgid
1 → sticky bit

Es poden combinar, igual que els permisos normals.

Per exemple:

4755 → setuid
2750 → setgid
1777 → sticky bit

10. Setuid

El bit setuid és el valor especial:

En fitxers executables, fa que el programa s’executi amb els permisos del propietari del fitxer.

Exemple clàssic:

/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:

4750
4640

11. Setgid

El bit setgid és el valor especial:

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:

chmod 2750 /mnt/AV/VM/peertube/data

El directori queda així:

drwxr-s---

La s en la part del grup indica que el setgid està activat.

Això ajuda a mantenir la coherència del grup:

Per això és recomanable per a directoris de dades gestionats per una aplicació.

12. Sticky bit

El sticky bit és el valor especial:

És típic en directoris compartits com:

/tmp

Un directori amb sticky bit pot aparèixer així:

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:

no és adequat per a directoris, perquè no dona execució/entrada.

Per a directoris de PeerTube proposem:

Que equival a:

drwxr-s---

Desglossat:

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:

Que equival a:

-rw-r-----

Desglossat:

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è:

equival aproximadament a:

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ò:

directoris → 2750
fitxers    → 640

és molt més net.

16. Permisos finals proposats

Al TrueNAS:

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:

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:

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:

2750 per directoris
640 per fitxers

18. Com validar després del canvi

Des del TrueNAS:

root@truenas:~# ls -lna /mnt/AV/VM/peertube/data | head

Resultat esperat:

drwxr-s--- 999 999 ...

Des de la VM PeerTube:

root@peer-tube:~# ls -lna /mnt/truenas-peertube/data | head

Buscar fitxers recents:

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:

root@peer-tube:/opt/peertube# docker compose logs -f peertube

I des de la web:

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:

/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:

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:

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:

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:

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:

PeerTube /data → 999:999
TrueNAS dataset → 999:999

Diagnosi SMTP PeerTube: `wrong version number`

1. Error observat

Als logs de PeerTube apareix:

Processing email in job 1.

i després:

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:

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:

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:

587 → secure false + STARTTLS true
465 → secure true + STARTTLS false

4. Què revisar al `.env`

A la VM PeerTube:

root@peer-tube:/opt/peertube# grep -i smtp .env

Cal mirar especialment:

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:

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:

TLS directe: no
STARTTLS: sí

Per això:

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:

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:

TLS directe: sí
STARTTLS: no

7. El cas que probablement tens ara

Pel missatge:

tls_validate_record_header:wrong version number

jo sospito una configuració així:

port 587
+
TLS directe activat

És a dir, probablement tens alguna cosa semblant a:

PEERTUBE_SMTP_PORT=587
PEERTUBE_SMTP_TLS=true

Això acostuma a petar.

Per a port 587, prova:

PEERTUBE_SMTP_PORT=587
PEERTUBE_SMTP_TLS=false
PEERTUBE_SMTP_DISABLE_STARTTLS=false

8. Aplicar canvi

Editar .env:

root@peer-tube:/opt/peertube# nano .env

Després reiniciar PeerTube:

root@peer-tube:/opt/peertube# docker compose restart peertube

Si vols reiniciar tot l’stack:

root@peer-tube:/opt/peertube# docker compose down
root@peer-tube:/opt/peertube# docker compose up -d

Mirar logs:

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:

root@peer-tube:/opt/peertube# docker compose exec peertube sh -c 'nc -vz smtp.domini.cat 587'

Per port 465:

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:

root@peer-tube:~# nc -vz smtp.domini.cat 587

o instal·lar eines al host:

root@peer-tube:~# apt install -y swaks openssl

10. Prova STARTTLS port 587

Des de la VM:

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:

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:

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:

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:

PEERTUBE_SMTP_PORT=587
PEERTUBE_SMTP_TLS=false
PEERTUBE_SMTP_DISABLE_STARTTLS=false

Per port 465:

PEERTUBE_SMTP_PORT=465
PEERTUBE_SMTP_TLS=true
PEERTUBE_SMTP_DISABLE_STARTTLS=true

També comprovar:

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:

usuari@domini.cat

però poses:

PEERTUBE_SMTP_FROM=noreply@altresdomini.cat

pot fallar o enviar a spam.

Millor començar amb:

PEERTUBE_SMTP_FROM=usuari@domini.cat

i després afinar.

15. Resum

L’error actual apunta fortament a una combinació incorrecta de TLS:

TLS directe contra un port que espera SMTP normal + STARTTLS

La correcció més probable, si uses port 587, és:

PEERTUBE_SMTP_TLS=false
PEERTUBE_SMTP_DISABLE_STARTTLS=false

Després:

root@peer-tube:/opt/peertube# docker compose restart peertube

I tornar a provar el reset de contrasenya.

Després:

Bash root@peer-tube:/opt/peertube# docker compose up -d --force-recreate peertube root@peer-tube:/opt/peertube# docker compose exec peertube env | grep -i SMTP root@peer-tube:/opt/peertube# docker compose logs -f peertube

Fase final pendent del desplegament PeerTube

1. Importació de vídeos / YouTube / yt-dlp

Objectiu:

Permetre que PeerTube pugui importar vídeos des d’URLs externes.

Això inclou:

YouTube
altres PeerTube
vídeos remots directes
altres plataformes compatibles amb yt-dlp

La peça tècnica important és:

yt-dlp

Abans es parlava molt de youtube-dl, però avui dia normalment es fa servir yt-dlp, perquè està més mantingut i suporta millor canvis de plataformes com YouTube.

Comprovacions

A la VM PeerTube:

root@peer-tube:/opt/peertube# docker compose exec peertube sh

Dins del contenidor:

which yt-dlp
yt-dlp --version
which youtube-dl
youtube-dl --version

Si no hi ha yt-dlp, cal decidir si:

1. La imatge PeerTube ja té mecanisme propi d’importació i només cal activar-lo.
2. Cal instal·lar o muntar yt-dlp.
3. Cal reconstruir una imatge derivada amb yt-dlp inclòs.

Prova funcional

Des de la interfície d’administració de PeerTube cal mirar:

Administration → Configuration → Import

I activar, si cal:

video import
URL import
user import permissions

Després provar amb un vídeo curt i no problemàtic.

2. Migració / importació des de la instància antiga PeerTube

Aquí cal distingir tres coses:

federar
importar
clonar

Federar

Federar vol dir que la nova instància pot seguir canals o comptes de l’antiga.

No és una còpia completa.

Serveix per:

veure contingut remot
seguir canals
validar ActivityPub
relacionar instàncies

Importar

Importar vol dir agafar un vídeo remot i incorporar-lo a la nova instància.

Això pot ser el camí més pràctic si volem portar contingut seleccionat de la instància antiga.

Clonar / migrar

Clonar tota la instància és una altra cosa.

Això implicaria:

base de dades
fitxers de vídeo
configuració
dominis
usuaris
canals
UUIDs
versions compatibles

No ho faria a cegues si la instància nova ja està funcionant i té domini/configuració pròpia.

3. Prova de federació entre instàncies

A la nova instància:

Administration → Configuration → Federation

Comprovar que la federació està activada.

Després provar:

buscar un canal remot de la instància antiga
seguir-lo
veure si apareixen vídeos remots
provar la reproducció

Això valida que la nova instància parla bé amb el món federat.

4. Prova d’importació des de la instància antiga

La prova mínima seria:

1. Agafar URL pública d’un vídeo de la instància antiga.
2. Des de la nova instància, fer import by URL.
3. Comprovar que descarrega.
4. Comprovar que transcodifica.
5. Comprovar que queda al NAS.
6. Comprovar que es reprodueix.

Després al TrueNAS podem veure si ha escrit fitxers nous:

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

5. Quota, permisos i política d’importació

Abans d’obrir importació a usuaris, cal decidir:

qui pot importar vídeos
quanta quota té cada usuari
mida màxima de fitxer
durada màxima
si cal moderació
si es permet importar de YouTube
si es permet importar només d’altres PeerTube

Perquè YouTube/yt-dlp pot consumir:

disc
CPU
temps de transcodificació
ample de banda

I també pot tenir implicacions de drets/copyright.

6. Backups

Ara que ja funciona, toca documentar o preparar còpies de seguretat.

Com a mínim:

/opt/peertube/.env
/opt/peertube/docker-compose.yml
/opt/peertube/docker-volume/config
/opt/peertube/docker-volume/db
/opt/peertube/docker-volume/redis
/mnt/AV/VM/peertube/data
/etc/apache2/sites-available/vm.domini.cat.conf
/etc/letsencrypt
/etc/fstab de la VM

La base de dades és crítica. No n’hi ha prou amb copiar vídeos.

7. Monitoratge bàsic

Comprovar regularment:

root@peer-tube:~# df -h
root@peer-tube:~# df -h /mnt/truenas-peertube
root@peer-tube:/opt/peertube# docker compose ps
root@peer-tube:/opt/peertube# docker compose logs --tail=100 peertube

Al TrueNAS:

root@truenas:~# du -sh /mnt/AV/VM/peertube/data

8. Documentació final

Ara ja tenim material per fer aquests documents:

01_creacio_vm_peertube.md
02_truenas_nfs_permisos.md
03_docker_compose_peertube.md
04_vhost_apache_certbot.md
05_postdesplegament_smtp_permisos.md
06_importacio_federacio_ytdlp.md
07_incidencies.md

La incidència Docker/Caddy/Snikket aniria a 07_incidencies.md.

Ordre recomanat ara

Jo faria aquest ordre:

1. Confirmar importació URL / yt-dlp dins PeerTube.
2. Provar importació d’un vídeo curt extern.
3. Provar importació d’un vídeo de la instància antiga.
4. Provar federació entre instància antiga i nova.
5. Decidir si volem migració selectiva o clonació completa.
6. Definir backups.
7. Tancar documentació.

Proxy RTMP per a emissions en directe

A més del proxy HTTPS habitual cap a PeerTube, cal tenir en compte que les emissions en directe amb OBS no entren per HTTP/HTTPS, sinó per RTMP.

En aquest desplegament, la part web de PeerTube funciona així:

Internet
   |
   | HTTPS 443
   v
CT Vhost / Apache
   |
   | HTTP intern 9000
   v
VM PeerTube
192.168.100.111:9000

Però les emissions en directe fan servir el port TCP 1935:

OBS
   |
   | RTMP TCP 1935
   v
CT Vhost / HAProxy
   |
   | TCP 1935
   v
VM PeerTube
192.168.100.111:1935

Per tant, Apache no resol aquesta part. Apache fa de reverse proxy per al web, però RTMP necessita un proxy TCP. En aquest cas es fa servir HAProxy al mateix CT Vhost.

Configuració de HAProxy

Al fitxer:

/etc/haproxy/haproxy.cfg

s’ha afegit el següent frontend/backend:

frontend rtmp_front
    bind *:1935
    mode tcp
    option tcplog
    default_backend peertube_rtmp

backend peertube_rtmp
    mode tcp
    server peertube 192.168.100.111:1935 check

Aquesta configuració fa que qualsevol connexió entrant al port 1935 del Vhost sigui reenviada cap al port 1935 de la VM PeerTube.

Validació de la configuració

Després de modificar HAProxy, cal validar la configuració:

root@Vhost:~# haproxy -c -f /etc/haproxy/haproxy.cfg

Si la configuració és correcta, es pot recarregar el servei:

root@Vhost:~# systemctl reload haproxy

O bé reiniciar-lo:

root@Vhost:~# systemctl restart haproxy

Comprovació del servei:

root@Vhost:~# systemctl status haproxy

Comprovació que HAProxy escolta al port RTMP:

root@Vhost:~# ss -ltnp | grep ':1935'

La sortida esperada és semblant a:

LISTEN 0 4096 0.0.0.0:1935 0.0.0.0:* users:(("haproxy",pid=...,fd=...))

Comprovació des del Vhost cap a PeerTube

Abans de provar OBS, és útil comprovar que el CT Vhost arriba al port RTMP de la VM PeerTube:

root@Vhost:~# nc -vz 192.168.100.111 1935

La resposta esperada és:

Connection to 192.168.100.111 1935 port [tcp/*] succeeded!

Comprovació a la VM PeerTube

A la VM PeerTube, el contenidor ha d’estar exposant el port 1935:

root@peer-tube:/opt/peertube# ss -ltnp | grep ':1935'

Sortida esperada:

LISTEN 0 4096 0.0.0.0:1935 0.0.0.0:* users:(("docker-proxy",pid=...,fd=...))
LISTEN 0 4096 [::]:1935 [::]:* users:(("docker-proxy",pid=...,fd=...))

Al docker-compose.yml, el servei peertube ha de tenir exposat el port:

ports:
  - "9000:9000"
  - "1935:1935"

Després de modificar aquest fitxer, cal recrear el contenidor:

root@peer-tube:/opt/peertube# docker compose up -d --force-recreate peertube

Prova amb OBS

L’usuari crea un directe des de PeerTube i copia la URL RTMP i la clau d’emissió.

A OBS:

Service: Custom
Server: rtmp://domini.exemple.cat:1935/live
Stream Key: CLAU_DEL_DIRECTE

És important no confondre el proxy HTTPS amb el proxy RTMP:

443  → Apache  → PeerTube:9000
1935 → HAProxy → PeerTube:1935

Incidència detectada

Durant les proves, OBS es connectava i es desconnectava en bucle. La causa era que el port públic 1935 encara estava associat a una instància PeerTube antiga en CT.

En apagar el CT antic, OBS deixava de trobar servidor. Això va permetre identificar que el trànsit RTMP no estava arribant a la nova VM PeerTube.

La solució va ser revisar HAProxy al CT Vhost i canviar el backend RTMP perquè apuntés a la nova VM:

server peertube 192.168.100.111:1935 check

Després de recarregar HAProxy, OBS va poder emetre correctament cap a la nova instància PeerTube.

223 KiB Raw Permalink Blame History Unescape Escape

ISO Ubuntu per a la VM PeerTube

ISO per a la VM PeerTube

Creació de la VM PeerTube

0. Descàrrega prèvia de la ISO Ubuntu Server

Decisió presa

Objectiu d’aquesta VM

Esquema general

Creació de la VM PeerTube

1. Creació de la màquina virtual a Proxmox

2. Inici de l’assistent de creació

3. Pestanya General

Valors recomanats

4. Decisió presa

5. Justificació

6. Resum de la pestanya General

7. Nota sobre el VM ID

8. Estat del procés

Creació de la VM PeerTube

2. Pestanya OS

Valors recomanats a la pestanya OS

Decisió presa

Justificació

Resum de la pestanya OS

Estat del procés

Creació de la VM PeerTube

3. Pestanya System

Valors recomanats a la pestanya System

Sobre el mode UEFI

Sobre les claus Secure Boot

Sobre el controlador SCSI

Sobre Qemu Agent

Sobre TPM

Decisió presa

Justificació

Resum de la pestanya System

Estat del procés

Creació de la VM PeerTube

4. Pestanya Disks

Valors recomanats a la pestanya Disks

Mida del disc

Decisió presa

Què NO volem guardar principalment en aquest disc

Bus del disc

Storage del disc

Format del disc

Cache

Discard

IO thread

SSD emulation

Backup

Resum de la pestanya Disks

Justificació

Esquema de decisió

Estat del procés

Creació de la VM PeerTube

4. Correcció de la pestanya Disks

Opció recomanada

Què és io_uring

Decisió presa

Justificació

Alternatives

Resum actualitzat de la pestanya Disks

Decisió final de la pestanya Disks

Creació de la VM PeerTube

5. Pestanya CPU

Valors recomanats a la pestanya CPU

Decisió presa

Justificació

Sobre el nombre de cores

Sobre sockets

Sobre NUMA

Sobre CPU limits

Resum de la pestanya CPU

Nota sobre transcodificació

Decisió final de CPU

Estat del procés

Creació de la VM PeerTube

5. Correcció de la pestanya CPU

Opció recomanada

223 KiB

Raw Permalink Blame History

Què és `io_uring`