escolteu.me/BASE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
bb7e08301c
BASE/choclo-NAV-PT-VM.md
Max HeadRoom bb7e08301c Upload files to "/"
2026-06-11 13:34:50 +02:00

11837 lines
223 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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