make sure tub.location and tub.port can be empty #2816
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#2816
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?
tub.port being empty means the node shouldn't do
Tub.listenOn
. We need to see how foolcap (and tahoe) reacts to either or both of these being empty.. I thinktub.location
needs to be set, but can be an empty string. I know it's fine to not callTub.listenOn()
, but I want to be sure that tahoe will do exactly that whentub.port
is empty, and that it isn't going to allocate a listening port.This ties into the anonymous mode (#1010 and #517). Anonymous-mode clients should leave both empty. Anonymous-mode servers, though, will populate them (with a
tor:ONION.onion:PORT
andtcp:LOCALPORT:interface=127.0.0.1
).(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:43) discusses the expected behavior of
tub.location
.Current ([2d8a1e865], 29-Aug-2016, pre-1.12) behavior of
tub.port
is:tub.port = STRING
:tcp:PORT
tcp:HOST
ortcp:HOST:interface=127.0.0.1
#tub.port =
(omitted entirely):NODEDIR/tub.port
is present, treat as PORT or endpoint stringtcp:PORT
toNODEDIR/tub.port
for future usetub.port =
(empty value): same astub.port =
(empty value)Current
tahoe create-client
/create-node
will write#tub.port =
intotahoe.cfg
, which means for most nodes that haven't been explicitly configured (probably to a deliberate port number), the key is missing entirely.The proposed change is to treat
tub.port =
(empty value) as instructions to not start up a Listener. While this is a change in behavior, I don't think many client nodes are likely to be configured with an empty string.(https://github.com/tahoe-lafs/tahoe-lafs/pull/324)
Note that the way to configure a client to not listen at all is to have this:
But don't do it like this, because it won't do the right thing:
or:
(if they're missing entirely, then tub.location will autodetect, and tub.port will either read the
NODEDIR/client.port
file or allocate a new port)I'm willing to believe that we need a more obvious "disabled" syntax here. Maybe something like:
but it's a bit awkward, given that tub.port is usually an endpoint string (so it's fairly open-ended), and tub.location is a comma-separated hints string (also open-ended). We could steal a few names from those namespaces to mean "disabled", but there's always going to be a bit of tension/syntax-violating going on.
In fea8b62/trunk:
At today's devchat, we agreed that an empty value is confusing, especially because it introduces a critical difference between "key is missing" and "key is present but value is empty" (one turns off the listener, the other turns on automatic port assignment). So I've reopened this, and I'm going to change it to:
and we'll reject any confusing cases that aren't already in use.
tahoe create-node
creates commented-out lines, which must continue to do automatic port/location (for backwards compatibility) for the "key missing" case:.. but which means we can reject "key present but value empty" cases, and throw an error at startup if we see:
I'll also add a constraint that if
tub.port = disabled
, thentub.location
must bedisabled
too, so they always show up as a pair. (and iftub.location = disabled
, thentub.port
must be too). I think that'll catch a lot of the confusing cases. "key is missing" and "value is missing" will mean different things, but instead of "X vs not X", it'll be "X vs error", which is probably safer.Oh, and we'll also change
tahoe create-node
to add a comment intahoe.cfg
, which explains the possible values for these keys.Reminding myself what the valid combinations are:
tcp:12345
ortcp:12345:morestuff
. tub.location is automatically set as aboveAUTO
, which is treated as aboveAUTO
In 076b389/trunk: