Grid Status displays wrong Address of connected storage servers #2818
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2818
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am connected to the public grid using our recently merged Tor integration features... however the grid status displays each storage server's address as:
UNIXAddress('/var/run/tor/socks')
Grid Status display wrong Address of storage serversto Grid Status displays wrong Address of storage serversGrid Status displays wrong Address of storage serversto Grid Status displays wrong Address of connected storage serversplease review
https://github.com/tahoe-lafs/tahoe-lafs/pull/331
Hm. Let's see.. this is just for client->server connections, and since the client is using unique Tubs (which aren't listening) for those connections, the connected address will always be that of the far end. Previously, by using a single shared (listening) Tub for all connections, sometimes the "client->server" connection would actually be running over a TCP connection that was initiated by the server (when both sides are running servers). At that time, it was useful to know whether your TCP connection was outbound or inbound. But since now they're always outbound, I guess we don't need to display the difference anymore.
There's two pieces of information that would be useful on this display. The first is where the server is advertising themselves (the connection hint). The second would be something about how we actually managed to connect to them.
It might be nice if this showed the fact that you're using Tor to connect to them. That's going to need some new Foolscap support though.. maybe it could remember which connection-handler was successful, and stash it on the Broker somewhere. Then we could add a new API (rref.getConnectionInfo?) which reported the name of the connection-handler and the hint which it used, maybe some other descriptive text.
I guess the only problem with displaying the connection hints is that they're slightly longer (
tcp:HOST:PORT
instead ofHOST:PORT
). Not a big deal.Foolscap#267 added to track a new API for this, although I think we should land this first, and think about enhancements later.
Hm, this patch is also a bit ugly when the server has multiple connection hints (which is what tub.location=AUTO always does). My test node (using direct TCP connections) is currently showing:
which gets wrapped into the little box, and doesn't tell me which of those connections actually got used.
I guess it's better than UNIXAddress, though. I think I'll land this and then prioritise adding the new Foolscap API to make it nicer, and see if I can get that into the next release.
In f88ae38/trunk:
I added #2819 for the beautification step.