Bonjour à tous,
Cela fait une semaine que les vidéos récentes ne sont plus listées sur mon instance peertube.
Où dois-je regarder pour comprendre ce qui se passe ?
Comment les nouvelles vidéos sont elles mise à jour ?
Par requète de l’instance qui suit ( pull ) ou bien par notification de l’instance qui est suivie (push) ?
Je pense qu’il s’agit de push et chaque instance prévient ses suiveurs ?
J’ai l’impression que mon instance ne reçoit plus les notifications mais est en mesure d’en envoyer.
La partie reception n’est pas évidente à tester cependant.
j’ai placé mon instance en debug ; dans production.yaml :
log: level: ‹ debug ›
et relancé le service systemctl restart peertube.
Puis j’ai arrété le suivi d’une autre instance sur laquelle j’ai la main et redemandé le suivi.
mon instance envoi bien la demande de retratit et la demande de suivi, et l’autre instance répond mais timeout après 1 seconde lors de sa réponse d’acceptation de suivi. :
traces d’erreur sur l’autre serveur :
error[21/09/2021 à 21:16:39] Cannot execute job 61 in queue activitypub-http-unicast.
{
« payload »: {
« uri »: « https://pire.artisanlogiciel.net/accounts/peertube/inbox »,
« signatureActorId »: 1,
« body »: {
« type »: « Accept »,
« id »: « SLVtv Vidéo à la demande PeerTube à Valbonne Sophia Antipolis »,
« actor »: « peertube - SLVtv Vidéo à la demande PeerTube à Valbonne Sophia Antipolis »,
« object »: {
« type »: « Follow »,
« id »: « https://pire.artisanlogiciel.net/accounts/peertube/follows/88 »,
« actor »: « https://pire.artisanlogiciel.net/accounts/peertube »,
« object »: « peertube - SLVtv Vidéo à la demande PeerTube à Valbonne Sophia Antipolis »
}
}
},
« err »: {
« stack »: « RequestError: connect ETIMEDOUT 109.210.47.42:443\n at ClientRequest. (/var/www/peertube/node_modules/got/dist/source/core/index.js:956:111)\n at Object.onceWrapper (events.js:520:26)\n at ClientRequest.emit (events.js:412:35)\n at ClientRequest.emit (domain.js:470:12)\n at ClientRequest.origin.emit (/var/www/peertube/node_modules/@szmarczak/http-timer/dist/source/index.js:39:20)\n at TLSSocket.socketErrorListener (_http_client.js:475:9)\n at TLSSocket.emit (events.js:400:28)\n at TLSSocket.emit (domain.js:470:12)\n at emitErrorNT (internal/streams/destroy.js:106:8)\n at emitErrorCloseNT (internal/streams/destroy.js:74:3)\n at processTicksAndRejections (internal/process/task_queues.js:82:21)\n at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16) »,
« message »: « connect ETIMEDOUT 109.210.47.42:443 »,
« name »: « RequestError »
}
}
sur mon instance j’ai par ailleurs fait un tcpdump du traffic sur 443 et effectivement la connection TLS est acceptée par nginx et des données applicatives sont reçues mais aucun réponse applicative n’est envoyée dans les 1s . après relecture du tcpdump il m’apparait que la connection entrante que j’ai regardée n’est pas celle de l’instance distante, il y a donc peut-être un problème réseau
et sur mon instance je cherche le texte ‹ Filtering › qui devrait à mon avis apparaitre dans peertube.log si peertube reçoit une requère activitypub alors qu’il est en mode debug, et là rien ( en fait si mais pour un autre acteur qui n’a rien à voir ).
Je suis donc en train de chercher entre nginx et peertube ce qui peut se passer…
Il s’agissait d’un problème réseau de résolution de nom.
Mon instance répond en ipv6 et en ipv4 et si on utilise l’alias ipv6 pour en obtenir l’ipv4 l’adresse n’était pas correcte.
Après correction de l’adresse ipv4, le suivi foncitonne à nouveau.
Les joies de de l’autohébergement, ma box a changé d’adresse et une seule partie de mes entrées dynamic dns ont été mises à jour.