[Résolu] Le download en HTTP est vicié sur ma seedbox

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Le download en HTTP est vicié sur ma seedbox

Mails

Bonjour,

J'utilise beaucoup de seedbox différentes (toutes rutorrent sur dédié)

Mais je viens d'en installer une sur un serveur Online, et pour la première je constate que lorsque je rapatrie mes fichiers directement depuis l'interface rtorrent (en double cliquant sur le fichier) le film arrive corrompu. Mais pas de soucis via FTP

Or c'est le seul serveur avec qui j'ai ce problème, comment cela peut s'expliquer ?
Quand je télécharger un fichier d'une autre seedbox de la même manière en même temps, aucun soucis. C'est vraiment cette seedbox

Mails

Après quelques essais (j'ai fait télécharger chez d'autres personnes), le film se coupe exactement au même moment que chez moi (44 minutes pour le film commun).

Cela peut venir d'une configuration ratée ou du matériel ?? Je compte réinstaller du coup

A noter pas de soucis pour les fichiers plus léger (non HD)

yonea11

Pour telecharger des gros fichiers en http il existe des logiciel qui evitent les pertes de données.. tu a essayé de ce coté là ? Je n'est aucun nom en téte dsl.. ;/

Edit : Flashget si ma memoire est bonne, etait un bon logiciel a l'epoque ^^

Mails

Non je n'ai pas essayé, mais ces logiciels servent si la connexion domestique décrochent, là c'est clairement le serveur. Jamais eu de soucis avant, surtout que ça décroche au même moment vu que les films sont corrompus à partir de la même minute. Je parierais plus sur un soucis logiciel compte tenu de ça

Mais ça me dépasse un peu

Merci de la réponse

Wagner

Bonsoir,

j'imagine, il s'agit d'un manque dans la conf(ig) de Nginx. À l'occasion, il m'est déjà arrivé de rencontrer ce problème. Dont j'ignore la solution... Comme évoqué, le FTP à palier au problème. Le télécharger de nouveau le corrigé seule parfois.
La réinstallation sera inutile, il faut parvenir à trouver ce manque...

Mails

Wagner wrote:Bonsoir,

j'imagine, il s'agit d'un manque dans la conf(ig) de Nginx. À l'occasion, il m'est déjà arrivé de rencontrer ce problème. Dont j'ignore la solution... Comme évoqué, le FTP à palier au problème. Le télécharger de nouveau le corrigé seule parfois.
La réinstallation sera inutile, il faut parvenir à trouver ce manque...

La réinstallation sera inutile ? Je repartirais de zéro du coup logiquement je referais pas la même erreur, quoique j'ai quasiment rien personnalisé dans le tutoriel de Magic (première fois que je l'utilise). Mais je suppose que si ça venait du tutoriel je serais pas le seul.
Télécharger de nouveau ? J'ai pas compris, tu parle de le re-rapatrier le fichier

Un troisième pote à télécharger un autre film, qui lui aussi s'arrête à 44 minutes. Encore plus étrange le film fait 5,5 gigas, et dans la fenêtre de téléchargement Firefox il fait 11 gigas ! Et dans le Finder (sous mac donc) il passe à 6,77 gigas. !!

Wagner

Oui, c'est étrange...
Bref, même avec une personnalisation, elle me semble toujours inutile. D'autant plus, si elle est minimal. Il devrait suffir de corriger la conf(ig) de Nginx.
Au pire, il est tout à fait possible de reprendre de zero (la conf(ig)). Nginx le comprendra sans problème.
Une réinstallation, c'est conseilllé (voir recommandé) lorsqu'il y a (au moins) un vrai problème. Là, pour moi, ce n'est le cas.

Mails wrote:Télécharger de nouveau ? J'ai pas compris, tu parle de le re-rapatrier le fichier

Oui, c'est bien ça.

Mails

J'ai tenté de rétélarger beaucoup beaucoup de fois, malheuresement ça n'a pas réglé le problème.

Je veux bien que tu m'aides à reprendre ma config, c'est quel fichier ? (chemin)

Wagner

Celui de ruTorrent, tout simplement. Normalement, c'est :

nano /etc/nginx/sites-enabled/rutorrent.conf

Cette commande permet de tester la conf(ig) de Nginx :

nginx -t ## ou ## service nginx configtest

Elle vérifie la syntaxe et retournera une erreur si tel est cas.

service nginx restart

Bien entendu, il faudra redémarrer Nginx. Ainsi, la nouvelle conf(ig) sera appliquée.

Mails

Le test ne nginx est positif pour la config de rutorrent :

server {
    listen 80;
     server_name ndd.tk;

    charset utf-8;
    index index.html index.php;
    client_max_body_size 10M;

    #ssl_certificate /etc/nginx/ssl/server.crt;
    #ssl_certificate_key /etc/nginx/ssl/server.key;

    access_log /var/log/nginx/rutorrent-access.log combined;
    error_log /var/log/nginx/rutorrent-error.log error;
    
    error_page 500 502 503 504 /50x.html;
    location = /50x.html { root /usr/share/nginx/html; }

    auth_basic "seedbox";
    auth_basic_user_file "/etc/nginx/passwd/rutorrent_passwd";
    
    location = /favicon.ico {
        access_log off;
        log_not_found off;
    }
    
    ## début config rutorrent ##

    location ^~ /rutorrent {
	root /var/www;
	include /etc/nginx/conf.d/php;
	include /etc/nginx/conf.d/cache;

	location ~ /\.svn {
		deny all;
	}

	location ~ /\.ht {
		deny all;
	}
    }

    location ^~ /rutorrent/conf/ {
	deny all;
    }

    location ^~ /rutorrent/share/ {
	deny all;
    }
    location /commun {
        include scgi_params;
        scgi_pass 127.0.0.1:5001;
        auth_basic "seedbox";
        auth_basic_user_file "/etc/nginx/passwd/rutorrent_passwd_commun";
    }
## début config seedbox-manager ##
 location ^~ / {
	root /var/www/seedbox-manager/public;
	include /etc/nginx/conf.d/php;
	include /etc/nginx/conf.d/cache;
    }
    ## fin config rutorrent ##

}

Wagner

Bien, le problème est touours présent, non ? Alors, il y a bien un manque... Comme c'est un flux http, avec l'une (voir plusieurs) des directives du module ngx_http_core_module, on devrait finir par trouver une solution.

Mails

Désolé pas compris

Oui problème toujours présent

Wagner

Pas de souci, je vais clarifié. En fait, j'imagine, les directives de ce module sont comme une piste. Afin de trouver le manque de la conf(ig) actuelle de Nginx. Et pour le savoir, il faudra mener des recherches ainsi que des test.
Là, deviner la solution me sera impossible...

Mails

Ma config est bien ici : /etc/nginx/nginx.conf

Si c'est ça elle est relativement courte, et rien qui s'apparente aux réglages cités plus haut

user www-data;
worker_processes auto;

pid /var/run/nginx.pid;
events { worker_connections 1024; }

http {
    include /etc/nginx/mime.types;
    default_type  application/octet-stream;

    access_log /var/log/nginx/access.log combined;
    error_log /var/log/nginx/error.log error;
    
    sendfile on;
    keepalive_timeout 20;
    keepalive_disable msie6;
    keepalive_requests 100;
    tcp_nopush on;
    tcp_nodelay off;
    server_tokens off;
    
    gzip on;
    gzip_buffers 16 8k;
    gzip_comp_level 5;
    gzip_disable "msie6";
    gzip_min_length 20;
    gzip_proxied any;
    gzip_types text/plain text/css application/json  application/x-javascript text/xml application/xml application/xml+rss  text/javascript;
    gzip_vary on;

    include /etc/nginx/sites-enabled/*.conf;
}

Wagner

En fait, la conf(ig) de ruTorrent repose sur ces deux fichiers :

nginx.conf

rutorrent.conf

Dans un sens, il forme un ensemble (ou tout). De plus, il serait tout à fait possible de n'en garder qu'un seul. C'est également vrai pour les directives. Par exemple, afin d'alléger (voir simplifier) la conf(ig), l'usage d'une seule directive root conviendrait (ou suffirait).

Certaines directives sont nécessaire. Tandis que d'autre non. C'est à voir selon chacun.

Mails

D'accord, mais ces deux fichiers sont présent sur ce topic, et dans aucun des deux je ne vois d'explications à mon problème. n'est-ce pas ?

Il me reste deux hosts, celui par defaut et celui de phpmyadmin, ça peut venir d'eux aussi ?

Wagner

En effet, quelqu'un ayant une bien grande connaissance de Nginx serait peut-être en mesure d'y arrivé.

Non, c'est impossible. Les vhosts sont indépendant.

Mails

Je viens de réinstaller, exactement le même soucis !

Ça vient du tutoriel ou du serveur

Wagner

Bonsoir,

j'avais prévenu. Bref, j'ai procéder à des test. Ainsi, je n'ai pas de raison de revoir mon avis. Rappel : c'est la conf(ig) de Nginx la cause et non le serveur.
Via le debug, j'ai obtenu ceci :

epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too (32: Broken pipe) while reading upstream
epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too (104: Connection reset by peer) while reading upstream
epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream

J'ai juste repris l'essentiel. Et non, actuellement, je n'ai aucune solution a proposé...

Mails

Ouais je sais que tu avais prévenu mais j'avais peur que l'on parte dans une mauvais piste à cause de moi, dans le sens que j'ai fais une modification après le tutoriel, et là au moins on sait que c'est la configuration issue du tutoriel. Mon serveur étant installé depuis deux jours, j'ai préféré perdre 40 minutes dans ce sens.

De mon côté j'ai aussi fait des tests (j'avais prévu mais c'est Jedediah qui m'a décidé à le faire ce soir), j'ai testé de télécharger toujours en HTTP mais depuis un listing. Donc un simple repertoire downloads accessible depuis mon navigateur issu d'un lien symbolique de mon repertoire de téléchargement.

Et là, diantre, le téléchargement en HTTP ne pose plus problème. Tout laisse à penser que c'est rutorrent qui ferme la connexion.

Le problème est moins gênant pour moi, vu que j'ai accès facilement au deux protocoles (j'aurais préféré via Rutorrent mais pas grave). Cependant ça serait cool qu'on trouve la solution pour l'intégrer au tutoriel de Magic, car jamais eu le même problème sur mes autres installations.

Page suivante »