Changing web server address breaks CLI #720

New Issue

tahoe-lafs · 2009-05-31T15:50:59Z

bewst commented

2009-05-31 15:50:59 +00:00

I wanted to access the web UI of a node from other nodes on my local subnet, so I had

[node]
web.port = tcp:3456:interface=192.168.188.10

where 192.168.188.10 is the local web address. Unfortunately the result was commands like "tahoe ls" wouldn't work, because (?) they seem to get to the grid by going through the local node's WAPI instead of talking to the grid with whatever mechanism the WAPI itself uses.

I wanted to access the web UI of a node from other nodes on my local subnet, so I had ```#!cfg [node] web.port = tcp:3456:interface=192.168.188.10 ``` where 192.168.188.10 is the local web address. Unfortunately the result was commands like "tahoe ls" wouldn't work, because (?) they seem to get to the grid by going through the local node's WAPI instead of talking to the grid with whatever mechanism the WAPI itself uses.

tahoe-lafs added the

labels 2009-05-31 15:50:59 +00:00

tahoe-lafs added this to the undecided milestone 2009-05-31 15:50:59 +00:00

warner commented

2009-05-31 21:01:11 +00:00

Yes.. partly that's by design. The CLI always talks to the local node's webapi: otherwise each CLI command would have to spin up a new client node, wait for it to connect to the introducer, learn about and connect to storage servers, etc. CLI commands are short-lived, but the long-running node acts like a daemon or agent for CLI and webapi requests.

The web.port specification allows you to control which interface the node will listen on (so you can restrict it to 127.0.0.1), but if you simply leave off the interface= part, it will listen on all interfaces. It sounds like you probably want to use:

[node]
web.port = tcp:3456

Each time the node starts up, it writes out NODEDIR/node.url with the fixed address of 127.0.0.1 and the current port number (this makes it easier to write unit tests which use web.port=tcp:0 and ask the kernel to assign a free port each time). So node.url (and therefore the CLI) assumes that the tahoe client node will at least be listening on 127.0.0.1 .

(you might also solve your problem by modifying node.url to point at 192.168.188.10, but since node.url is overwritten each time the node starts, you'd need to put your node somewhere other than ~/.tahoe . Simply removing the interface restriction sounds like a better solution).

Do you think it'd be enough to improve source:docs/configuration.txt to make it clear that interface= is optional, and that "tcp:3456" is the most likely value that you'd want to change web.port to have?

Yes.. partly that's by design. The CLI always talks to the local node's webapi: otherwise each CLI command would have to spin up a new client node, wait for it to connect to the introducer, learn about and connect to storage servers, etc. CLI commands are short-lived, but the long-running node acts like a daemon or agent for CLI and webapi requests. The web.port specification allows you to control which interface the node will listen on (so you can restrict it to 127.0.0.1), but if you simply leave off the interface= part, it will listen on all interfaces. It sounds like you probably want to use: ``` [node] web.port = tcp:3456 ``` Each time the node starts up, it writes out NODEDIR/node.url with the fixed address of 127.0.0.1 and the current port number (this makes it easier to write unit tests which use web.port=tcp:0 and ask the kernel to assign a free port each time). So node.url (and therefore the CLI) assumes that the tahoe client node will at least be listening on 127.0.0.1 . (you might also solve your problem by modifying node.url to point at 192.168.188.10, but since node.url is overwritten each time the node starts, you'd need to put your node somewhere other than ~/.tahoe . Simply removing the interface restriction sounds like a better solution). Do you think it'd be enough to improve source:docs/configuration.txt to make it clear that interface= is optional, and that "tcp:3456" is the most likely value that you'd want to change web.port to have?

warner added

code-frontend-cli

and removed

unknown

labels 2009-05-31 21:01:11 +00:00

davidsarah commented

2010-06-12 22:34:00 +00:00

Should the gateway always listen on 127.0.0.1? I can see why you would want to use interface to restrict to listening on 127.0.0.1, but why would you want to exclude the local interface?

Should the gateway always listen on 127.0.0.1? I can see why you would want to use `interface` to restrict to listening on 127.0.0.1, but why would you want to exclude the local interface?

Sign in to join this conversation.