Jump to content

Cannot connect (Debian)


vandan

Recommended Posts

Hi!

Thanks for the Linux server version. I know this is an early alpha and it's not supposed to fully work, but I cannot even get it to accept connections :)

$ cat utserver.conf

webui_serve_files: false

dir_completed: /data/unsorted/

dir_download: /data/movies/

dir_download: /data/series/

dir_download: /data/music/

bind_port: 32993

ul_slots_per_torrent: 10

max_total_connections: 400

auto_bandwidth_management: false

seed_ratio: 110

$ ./utserver

server started

IPv6 is installed

I have unzipped the webUI directory to an Apache web directory /var/www

webUI cannot connect ("can't talk to client"), although lynx shows a difference if i try to connect to localhost:8080 ("waiting for response" vs. "unable to connect" on an unused port)

Appreciate any hints.

Link to comment
Share on other sites

@DreadWingKnight: Hey. I DID follow the documentation. As I already have Apache running and serving a lot of useful stuff, why would I want to have another HTTP server on a different port, without my proper authentification etc? And of course I have to extract the UI for Apache.

The documentation does NOT say what Firon says, to NOT use Apache to serve the files.

I don't see the technical necessity to reverse proxy access to another process serving HTTP, but okay, I'll do that. And I don't see why that would be "hell bent on making it work", because reverse proxying is a two-liner.

Why would I want to allow an alpha software to answer HTTP requests openly for the whole net? I'm not crazy.

@garoto: If you got it to run, why don't you post your conf as example?

Link to comment
Share on other sites

@DreadWingKnight: Hey. I DID follow the documentation. As I already have Apache running and serving a lot of useful stuff, why would I want to have another HTTP server on a different port, without my proper authentification etc? And of course I have to extract the UI for Apache.

The documentation does NOT say what Firon says, to NOT use Apache to serve the files.

I don't see the technical necessity to reverse proxy access to another process serving HTTP, but okay, I'll do that. And I don't see why that would be "hell bent on making it work", because reverse proxying is a two-liner.

Why would I want to allow an alpha software to answer HTTP requests openly for the whole net? I'm not crazy.

@garoto: If you got it to run, why don't you post your conf as example?

You need to reverse proxy because the WebUI talks to the client through HTTP. So naturally, you have to reverse proxy the requests to it, even if you don't serve the files with utserver.

Link to comment
Share on other sites

I don't want to be an ass (posted in the announce thread already), but couldn't you guys provide a sample .conf file plus comments? ^_^

I got it to run on a Debian Lenny 64-bit, but a sample conf file would make my life much easier.

We'll provide a sample config on the next version or so. It'll make it a little easier than having to read the docs to make your own, I guess.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...