introducers.yaml causes foolscap assertion #2862
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
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2862
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?
User "lazygravy" on IRC reported a node-startup exception that happens when
private/introducers.yaml
is used. The problem appears to be that the FURL given to foolscap is a unicode string, and there is code inside foolscap which asserts that the connection hints it sees are normal strings (not unicode). The exception (as recorded in twistd.log) looks like:I think the code that loads the YAML file needs to do an
.encode("ascii")
on any of the FURLs it extracts, before passing them to foolscap.In addition, docs/configuration.rst had an invalid example for the
private/introducers.yaml
section (around line 920). It said:but that will result in a data structure like
introducers = {"petname2": "furl = FURL2"}
, which causes an exception at node startup time like this:Instead, the docs should recommend:
I assembled a patch: PR in https://github.com/tahoe-lafs/tahoe-lafs/pull/391 is testing now
In 582931b/trunk:
In 64e344b/trunk:
A comment on https://blog.torproject.org/blog/tor-heart-tahoe-lafs (January 6, 2017 by Anonymous) sounds possibly related to this (can't link directly to the comment):
After a series of tests and debugging, I managed to have the test Tahoe-LAFS tor hidden service Storage-Client nodes connect to one another without a Introducer and only using the servers.yaml file. It appears there is a slight bug in the servers.yaml coding which makes it presently necessary to add a #comment between the storage node entrys to be successful. To save the readers the effort and time I'll paste in a working server.yaml file with fictional node names, onion addresses and id strings. However the spaces and syntax must be exactly copied if you want this to work for you after changing to your Storage nicnames, Onion addresses and the Storage key Id strings located after ann: in your introducer_default_cache.yaml file.
example of locating the desired announce string to copy to your server.yaml file
~/.tahoe/private/introducer_default_cache.yaml
search for
and
Create, add these strings to your new server.yaml file keeping the #storage: comment line between each added storage node using a text editor.
Next, comment the introducer in your tahoe.cfg file #introducer.furl = pb:/ and then start/restart your tahoe node which in a few seconds should then successfully only connect to your Tahoe-LAFS tor hidden service storage nodes without a Introducer.