tahoe-lafs/trac-2024-07-25

bad connection hint in tub.location works once #2056

New issue

Open

opened 2013-08-08 20:59:48 +00:00 by leif · 0 comments

leif commented

2013-08-08 20:59:48 +00:00

Owner

If a node is started with an invalid foolscap location hint specified in its tub.location, it will startup successfully once but subsequent times it will fail because it has written the invalid location hint into its logport and control furls (and its storage furl, if storage is enabled).

Steps to reproduce:

tahoe create-client foo
Edit foo/tahoe.cfg and set tub.location = fake.location
tahoe start foo
Observe node is running at http://127.0.0.1:3456/
tahoe restart foo
Observe that node is not running. This reveals why:

$ grep -r fake.location foo/ 
foo/private/logport.furl:pb://qk2roikwmskxr72qpacrj3xw4tow345j@fake.location/tavvmg2xrnyaugj4lchlzpfmqsv6xlix
foo/private/control.furl:pb://qk2roikwmskxr72qpacrj3xw4tow345j@fake.location/scoki24fb2ywcfnsrrc4ryubv6obxmze
foo/logs/twistd.log:	foolscap.referenceable.BadFURLError: bad connection hint 'fake.location' (hostname, but no port)
foo/logs/twistd.log:2013-08-08 20:35:59+0000 [-] [Failure instance: Traceback: <class 'foolscap.referenceable.BadFURLError'>: bad connection hint 'fake.location' (hostname, but no port)
foo/tahoe.cfg:tub.location = fake.location

Ordinarily when tub.location is changed, upon restart the .furl files are updated with the new location hint. When they contain bad connection hints, however, tahoe hits the exception before it gets to rewriting them. So, to recover from this situation, the furl files must be manually modified or deleted.

I reckon the location hint should be validated before being written to these files, and the initial startup should fail.

It would also be nice if tahoe start would notice when startup fails and print the exception.

If a node is started with an invalid foolscap location hint specified in its `tub.location`, it will startup successfully once but subsequent times it will fail because it has written the invalid location hint into its logport and control furls (and its storage furl, if storage is enabled). Steps to reproduce: 1. `tahoe create-client foo` 2. Edit `foo/tahoe.cfg` and set `tub.location = fake.location` 3. `tahoe start foo` 4. Observe node is running at <http://127.0.0.1:3456/> 5. `tahoe restart foo` 6. Observe that node is not running. This reveals why: ``` $ grep -r fake.location foo/ foo/private/logport.furl:pb://qk2roikwmskxr72qpacrj3xw4tow345j@fake.location/tavvmg2xrnyaugj4lchlzpfmqsv6xlix foo/private/control.furl:pb://qk2roikwmskxr72qpacrj3xw4tow345j@fake.location/scoki24fb2ywcfnsrrc4ryubv6obxmze foo/logs/twistd.log: foolscap.referenceable.BadFURLError: bad connection hint 'fake.location' (hostname, but no port) foo/logs/twistd.log:2013-08-08 20:35:59+0000 [-] [Failure instance: Traceback: <class 'foolscap.referenceable.BadFURLError'>: bad connection hint 'fake.location' (hostname, but no port) foo/tahoe.cfg:tub.location = fake.location ``` Ordinarily when `tub.location` is changed, upon restart the .furl files are updated with the new location hint. When they contain bad connection hints, however, tahoe hits the exception before it gets to rewriting them. So, to recover from this situation, the furl files must be manually modified or deleted. I reckon the location hint should be validated before being written to these files, and the initial startup should fail. It would also be nice if `tahoe start` would notice when startup fails and print the exception.