Cannot connect (Debian)

[vandan]

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.

[DreadWingKnight]

Follow the documentation next time. You aren't supposed to extract the webui zip.

http://<ip>:32993/gui/

[Firon]

Don't use Apache to serve up the files. It'll be much easier to have ut itself do it. But if you're hell bent on making it work, then you'll have to have Apache reverse proxy to utserver.

[garoto]

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.

[vandan]

@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?

[DreadWingKnight]

Except that access to the utserver webui is authenticated.

And the documentation also didn't say to do what you did.

[surftheair]

hey, I'm having the same problem on a centos server, the utserver doesn't seem to be listening for connections

[Firon]

@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.

[Firon]

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.