key-generator dones't work anymore #542

Closed
opened 2008-12-01 04:37:01 +00:00 by warner · 3 comments
warner commented 2008-12-01 04:37:01 +00:00
Owner

Jan-Benedict Glaw noticed that the key-generator no longer works:

% ./bin/tahoe create-key-generator -C kg
% ./bin/tahoe start -C kg

  File "tahoe-key-generator.tac", line 7, in <module>
    k = key_generator.KeyGeneratorService(2048)
  File "src/allmydata/key_generator.py", line 82, in __init__
    self.tub = foolscap.Tub(certFile=os.path.join(self.basedir, 'key_generator.pem'))
  File "/usr/lib/python2.5/posixpath.py", line 62, in join
    elif path == '' or path.endswith('/'):
exceptions.AttributeError: 'int' object has no attribute 'endswith'

Looks like the .tac file is being created with an obsolete key-length
argument, which is being interpreted as a basedir.

Jan-Benedict Glaw noticed that the key-generator no longer works: ``` % ./bin/tahoe create-key-generator -C kg % ./bin/tahoe start -C kg File "tahoe-key-generator.tac", line 7, in <module> k = key_generator.KeyGeneratorService(2048) File "src/allmydata/key_generator.py", line 82, in __init__ self.tub = foolscap.Tub(certFile=os.path.join(self.basedir, 'key_generator.pem')) File "/usr/lib/python2.5/posixpath.py", line 62, in join elif path == '' or path.endswith('/'): exceptions.AttributeError: 'int' object has no attribute 'endswith' ``` Looks like the .tac file is being created with an obsolete key-length argument, which is being interpreted as a basedir.
tahoe-lafs added the
code
major
defect
1.2.0
labels 2008-12-01 04:37:01 +00:00
tahoe-lafs added this to the undecided milestone 2008-12-01 04:37:01 +00:00
zooko commented 2008-12-01 13:16:46 +00:00
Author
Owner

Do we need it? If we don't, then let's remove it rather than leave it there, broken, so that its presence won't waste the time of people like Jan-Benedict.

Do we need it? If we don't, then let's remove it rather than leave it there, broken, so that its presence won't waste the time of people like Jan-Benedict.
warner commented 2008-12-01 22:45:10 +00:00
Author
Owner

Yes, we do. We don't have DSA keys yet, and we haven't done anything to speed
up RSA key generation for a long time. As best I can tell, the prodnet key
generator was using 10-20% of a core in september (before the number dropped
to zero, possible because it was somehow broken, or not started), which is
time that would have to be spent (blocking) in the webapi node if there were
no helper.

It would be nice to be able to provide a more objective argument. We don't
have any automated client-experience instrumentation: if we did, we could
turn the helper on and off and then watch how long a typical user must wait
to create a directory with and without it, and then say "to save each user an
average of 1.5 seconds per directory creation, it is worth having this code
in place, and fixing it". As it stands, I can only claim that it is likely to
save each user an average of 700ms (the SSK-creation time as measured by
http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_speedstats_SSK_creation.html),
and therefore is worth having this code in place and fixing it.

Note that the prodnet key generator is still working because its .tac file
was created before this bug was introduced.

When we get DSA dirnodes, I'll be happy to rip out the key-generator.

Yes, we do. We don't have DSA keys yet, and we haven't done anything to speed up RSA key generation for a long time. As best I can tell, the prodnet key generator was using 10-20% of a core in september (before the number dropped to zero, possible because it was somehow broken, or not started), which is time that would have to be spent (blocking) in the webapi node if there were no helper. It would be nice to be able to provide a more objective argument. We don't have any automated client-experience instrumentation: if we did, we could turn the helper on and off and then watch how long a typical user must wait to create a directory with and without it, and then say "to save each user an average of 1.5 seconds per directory creation, it is worth having this code in place, and fixing it". As it stands, I can only claim that it is likely to save each user an average of 700ms (the SSK-creation time as measured by <http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_speedstats_SSK_creation.html>), and therefore is worth having this code in place and fixing it. Note that the prodnet key generator is still working because its .tac file was created before this bug was introduced. When we get DSA dirnodes, I'll be happy to rip out the key-generator.
warner commented 2008-12-01 23:48:24 +00:00
Author
Owner

Fixed, in changeset:71c62f8fcb823eb5.

Fixed, in changeset:71c62f8fcb823eb5.
tahoe-lafs added the
fixed
label 2008-12-01 23:48:24 +00:00
tahoe-lafs modified the milestone from undecided to 1.3.0 2008-12-01 23:48:24 +00:00
warner closed this issue 2008-12-01 23:48:24 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#542
No description provided.