J’ai une instance Peertube en v3.0.1 sur un serveur Debian auto-hébergé via Docker. Je n’utilise pas Traefik ou le « webserver » fournit avec l’image Docker mais j’utilise Apache en reverse-proxy car j’ai d’autres services sur cette machine comme Diaspora* ou d’autres sites web. Cette infrastructure fonctionne depuis deux ans et depuis deux ans j’ai un problème que je n’arrive pas à résoudre. Peertube ne détecte pas bien l’adresse IP du visiteur. Du coup le compteur de vues déconne (c’est pas bien grave) mais surtout je pense que c’est à cause de ça que je n’arrive pas à faire fonctionner la fonction LIVE (OBS n’arrive pas à établir la connexion avec le serveur). Dans mon fichier de config production.yaml (j’ai cru voir que le toml était supporté maintenant) j’ai bien trust_proxy : - 'loopback' et mes compétences ne me permettent pas d’aller plus loin.
trust_proxy devrait comporter l’adresse interne de ton serveur Apache, soit 172.18.0.1. Mais comme cette adresse est susceptible de changer au fil des redémarrages, il vaut mieux mettre toute la classe d’IP de ton serveur. J’ai mis ça pour le mien : 172.0.0.0/8.
Je viens d’essayer de mettre 172.0.0.0/8 à la place de loopback. J’ai redémarré docker-compose (docker-compose stop && docker-compose up -d) mais sans succès. Peut-être que je dois complètement relancer les conteneurs avec docker-compose down && docker-compose up -d pour que la modification du fichier de config soit prise en compte ?
Apache ajoute-t-il bien les en-têtes X-Forwarded-For et X-Real-IP ?
En effet, derrière un reverse proxy, l’ip que verra Peertube sera celle … du reverse proxy.
Il faut donc que celui-ci ajoute l’ip du client dans des en-têtes spécifiques (cf les entêtes citées, utilisées par exemple dans la config nginx recommandée : https://github.com/Chocobozzz/PeerTube/blob/develop/support/nginx/peertube )
Pour le live, je ne pense pas que ce soit ça, ça ne passe pas par le reverse proxy. Il faut probablement ouvrir le port 1935.
Pour faire tourner plusieurs services différents, certains avec apache, d’autres avec nginx, une solution simple est d’utiliser HAProxy pour ajouter une couche de proxy devant.
Voici un exemple de fichier de configuration (/etc/haproxy/haproxy.cfg) :
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend http-in
bind 192.168.0.171:80
bind :::80 v6only
mode http
acl acl_apache hdr(host) mon.domain1.yyy
acl acl_apache hdr(host) mon.domain2.yyy
acl acl_nginx hdr(host) mon.domain3.yyy
use_backend backend_apache if acl_apache
use_backend backend_nginx if acl_nginx
frontend https-in
bind 192.168.0.171:443
bind :::443 v6only
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend backend_apache_ssl if { req_ssl_sni -i mon.domain1.yyy }
use_backend backend_apache_ssl if { req_ssl_sni -i mon.domain2.yyy }
use_backend backend_nginx_ssl if { req_ssl_sni -i mon.domain3.yyy }
backend backend_apache
mode http
option forwardfor except 127.0.0.1
server apache 127.0.0.2:80
backend backend_apache_ssl
mode tcp
option ssl-hello-chk
server apache 127.0.0.2:443 send-proxy-v2
backend backend_nginx
mode http
option forwardfor except 127.0.0.1
server nginx 127.0.0.3:80
backend backend_nginx_ssl
mode tcp
option ssl-hello-chk
server nginx 127.0.0.3:443 send-proxy-v2
Ensuite, pour les config apache, il ne faut écouter que sur l’ip spécifique (ici 127.0.0.2).
Par exemple, en modifiant le fichier /etc/apache2/ports.conf :
ok merci pour les infos. Pas le choix d’utiliser Nginx alors si je comprends bien. Je vais voir pour basculer tous mes services sur nginx alors ou le faire cohabiter avec Apache. Mais là je ne peux pas me lancer dans cette aventure dans l’immédiat. Je reviendrai si j’ai besoin d’aide et/ou pour donner les résultats.
C’est théoriquement possible de configurer Apache pour fonctionner avec Peertube. Seulement il n’y a pas de documentation officielle. Ce qui doit manquer dans votre cas, c’est l’instruction pour ajouter les en-têtes x-Forwarded-For et X-Real-IP. Apache sait le faire. Je n’ai pas la configuration en tête, il faut regarder la doc.
Ça corrigera le premier problème, celui de Peertube qui ne voit pas les bonnes IPs.
Pour le live, je pense que c’est autre chose (ça doit juste être un problème de port 1935 bloqué par Docker ou un firewall).
La solution avec HAProxy est une solution «simple» pour vous laisser le choix, application par application, de quel serveur utiliser (apache, nginx, autre…). C’est ce que j’utilise personnellement. Comme ça, je peut avoir un nextcloud avec Apache, un Peertube avec nginx, etc.
HAProxy se met de manière transparente devant chaque service et redirige les connexions au bon endroit.
C’est assez rapide à mettre en place comme configuration. Je reconnais que ce n’est pas forcément simple à comprendre, mais normalement en suivant les instructions que j’ai donné, ça doit se faire rapidement (j’espère que je n’ai rien oublié).
Une solution que je n’ai pas mentionnée : si jamais vous avez accès à plusieurs IPs publiques, c’est encore plus simple. Apache sur une IP, nginx sur l’autre, et voilà.
J’étais déjà tombé sur cet article et j’avais mis en place le module remoteip avec la config expliquée dans l’article. Sans succès malheureusement. L’adresse IP retournée par Peertube dans la capture d’écran ci-dessus est en fait la passerelle du réseau Docker et non l’adresse interne du reverse-proxy :
En lisant ce topic, je me demande si je ne serais pas mieux à garder le webserver fourni avec le docker-compose de Peertube et de placer le tout derrière Apache ?
Je ne connais pas bien Apache en ce qui me concerne. Donc je n’ai pas trop de pistes de ce côté. Ce que je peux affirmer avec certitude c’est que ça marche très bien avec le reverse proxy nginx-proxy, sans besoin d’activer le composant webserver.
Si Apache n’est pas correctement configuré je ne pense pas qu’activer webserver change quelque chose. Tu peux tout de même le tenter car ça ne coûte pas trop cher.
Sinon faire des tests avec un docker type « Hello World! » qui serait capable d’afficher cette info. Ça doit bien exister quelque part sur Docker Hub.
du coup, je ne vois pas bien la différence entre la variable d’environnement PEERTUBE_TRUST_PROXY et trust_proxy du fichier production.yaml… et je ne comprends pas pourquoi je n’ai pas besoin de rajouter 172.18.0.0/16 dans ce dernier. Si qqun a une explication, je suis preneur. J’aurais aimé pouvoir éditer le topic aussi pour ajouter Apache et Docker soit dans le titre soit en mots-clés, soit les deux
Je n’en suis pas certain, mais j’intuite que la valeur de trust_proxy définie dans /config/default.yaml ou /config/production.yaml est écrasée par la variable d’environnement PEERTUBE_TRUST_PROXY, via le traitement du fichier /config/custom-environment-variables.yaml.
