`assign_attributes': undefined method `iso8601' for Time:Class (NoMethodError) about letsencrypt-webfaction

[flan]

$ ruby2.2 --version
ruby 2.2.5p319 (2016-04-26 revision 54774) [x86_64-linux-gnu]

$ cat /etc/redhat-release
CentOS release 6.8 (Final)

[flan]

I just encountered the same thing while setting it up.

The module doesn't get 'time' from anywhere; adding "require 'time'" to the top of authorization.rb made it pass for me.

I also needed to add "require 'fileutils'" to the top of domain_validator.rb.

It still doesn't work after those changes, though, appearing to time out while doing a trial run against https://acme-staging.api.letsencrypt.org/ : domain_validator.rb:24:in 'validate!': Failed to verify statuses in 10 seconds. (RuntimeError)

[flan]

Er, no, it seems to be working fine with those changes. I had a www-redirect domain in my list, so that was causing the timeout.

[will-in-wi]

I think I know what caused the issue. Acme::Client just removed a dep on ActiveSupport which was probably providing autoloading. The files in question are actually in the https://github.com/unixcharles/acme-client rather than mine. I'll look into it and try to get a fix upstream.

Thanks for reporting! I'll try and get something figured out soon.

[will-in-wi]

Could you try version 1.1.6 and see if that works for you? I just released it and it should fix this issue.

Thanks!

[flan]

Nope, back to undefined method 'iso8601' for Time:Class (NoMethodError) in authorization.rb.

[flan]

It's possible that it didn't recursively update whatever it was supposed to update, though. The output to stdout only mentioned upgrading letsencrypt-webfaction, nothing else; I followed the System Ruby install instructions from the readme.

I wish I could dig deeper, but the style of Ruby in the files I've looked at today is pretty foreign to me.

[will-in-wi]

I'll look deeper. Could you double-check that you are using ruby2.2? And which server OS are you on?

[will-in-wi]

Is there a longer backtrace than just the error line? I can't reproduce this, it works fine on my server. I'm trying to figure out how to reproduce so that I can demonstrate the need for the patch upstream.

[flan]

~/.letsencrypt_webfaction/gems/gems/acme-client-0.4.0/lib/acme/client/resources/authorization.rb:28:in `assign_attributes': undefined method `iso8601' for Time:Class (NoMethodError)
        from ~/.letsencrypt_webfaction/gems/gems/acme-client-0.4.0/lib/acme/client/resources/authorization.rb:11:in `initialize'
        from ~/.letsencrypt_webfaction/gems/gems/acme-client-0.4.0/lib/acme/client.rb:58:in `new'
        from ~/.letsencrypt_webfaction/gems/gems/acme-client-0.4.0/lib/acme/client.rb:58:in `authorize'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:28:in `block in authorizations'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:28:in `map'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:28:in `authorizations'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:32:in `challenges'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:40:in `write_files!'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:10:in `validate!'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/application.rb:24:in `run!'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/exe/letsencrypt_webfaction:5:in `<top (required)>'
        from ~/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction:23:in `load'
        from ~/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction:23:in `<main>'

If I hack in "require 'time'", I get this:

~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:42:in `block in write_files!': uninitialized constant LetsencryptWebfaction::DomainValidator::FileUtils (NameError)
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:40:in `each'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:40:in `write_files!'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:10:in `validate!'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/application.rb:24:in `run!'
        from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/exe/letsencrypt_webfaction:5:in `<top (required)>'
        from ~/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction:23:in `load'
        from ~/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction:23:in `<main>'

I've got a working certificate from hacking in both of the lines mentioned a few hours ago, so there's no urgency on my side.

[flan]

If it helps, these both seem like really commonly used libraries, so it's possible that there's some magic going on, where your interpreter is preloading a bunch of frequently-used things.

I don't know enough about Ruby to really understand its namespace boundaries, though.

[flan]

To further clarify, Python has something like that from its site.py hooks, used to handle enumeration and access to non-standard libraries (basically logic that handles indexing the equivalent of gems). They're not something most people ever notice, since they usually just populate import paths and do other completely benign things and they're usually only touched by distro maintainers, but they have the ability to execute logic, which can be used to do some interesting tricks that can't easily be traced.

It wouldn't surprise me at all if Ruby has something similar and it's either broadly taken for granted or it was accidentally left out of whatever is in the vanilla packages installed by default on this version of CentOS. I haven't touched Ruby in my environment at all before now.

[flan]

I just came across autoload?(name) in http://ruby-doc.org/core-2.1.0/Module.html

I don't really have a good grasp of what a "module symbol" is, but

irb(main):001:0> autoload?('time')
=> nil
irb(main):002:0> autoload?(:Time)
=> nil
irb(main):003:0> autoload?(:iso8601)
=> nil

Maybe your environment differs. If so, this might be an issue WebFaction will need to look into, or it could be a poor assumption by upstream.

[will-in-wi]

That's what I'm trying to determine… It looks like the time library is pulled in inside the main acme client library, and from my testing, that should work. My server works, both my and the destination test suites work…

I'm stumped. I could probably figure it out if I had access to your app and could attach a debugger, but that's not feasible.

I'm still looking and trying to figure out what on earth is happening…

[flan]

I can probe the environment as much as you'd like if there's anything you can think of that I could check.

While I can't give you a native shell, we could use something like coderpad to proxy a debug session.

[will-in-wi]

Hey! I got it to fail by deleting my installation on another account and starting from scratch. I'll try and figure out the issue there.

[will-in-wi]

In walking through the code, I realized that they just fixed this in the upstream source, which is why I didn't see it: unixcharles/acme-client#95

I've requested a patch release. In the meantime, manually applying the patch in the merge request above is a good solution.

[flan]

Done and it works to pass the first check.

Now there's just the fileutils dependency issue, which looks like something you have control over.

[will-in-wi]

Indeed I do: 5864c09

That patch should fix it. I'll hold off on a release until Acme::Client pushed a fix for the time issue. Then I'll push a fix which requires that version.

Thanks!

[flan]

Yay!

Thanks for being so quick to respond to this problem! It's great to have people like you helping out with advancing web infrastructure.

[will-in-wi]

My pleasure, thanks for reporting issues and being responsive to requests for more information!

Thanks for solving the issue so quickly. I upgraded to version 1.1.6.
From the comments to this post I learn that I have to fix tow things ...

First thing, you wrote:
I've requested a patch release. In the meantime, manually applying the patch in the merge request above is a good solution.

You mean adding this line:
@expires = Time.iso8601(body['expires']) if body.key? 'expires'
to def assign_attributes(body) in authorization.rb

Second thing:

Add:
require 'fileutils'
at the top of domain_validator.rb

Could you please confirm that these are the right steps to fix the issue?

In the directory .letsencrypt_webfaction/gems/gems
I now have two versions of letsencrypt_webfaction-
version 1.1.5 and 1.1.6 is it save to delete the directory
letsencrypt_webfaction-1.1.5

Best,

Annet V.

[will-in-wi]

@AnneVerme There are two patches to manually apply:

unixcharles/acme-client@3a133df and 5864c09

The filenames are at the top of the diff. The former patch applies to acme-client, and the latter applies to letsencrypt-webfaction.

You are safe to remove the old version of letsencrypt webfaction. However, it doesn't hurt anything by being there.

[ratkobucic]

Hm, guys I have same issue with SSL issue for one domain hosting wordpress... after I applied both patches, initial error was gone, but now I getting another one (even I update timeout to 30 sec):

CentOS release 6.8 (Final)
$ letsencrypt_webfaction --version
1.1.6
$ ruby2.2 --version
ruby 2.2.5p319 (2016-04-26 revision 54774) [x86_64-linux-gnu]

~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/domain_validator.rb:24:in `validate!': Failed to verify statuses in 30 seconds. (RuntimeError)
from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/lib/letsencrypt_webfaction/application.rb:24:in `run!'
from ~/.letsencrypt_webfaction/gems/gems/letsencrypt_webfaction-1.1.6/exe/letsencrypt_webfaction:5:in `<top (required)>'
from ~/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction:23:in `load'
from ~/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction:23:in `<main>'

After manually applying the two patches generating a certificate works with no errors.
I am running a Python application at webfaction.

Best,

Annet V.

[flan]

@ratkobucic

That's a different problem, which, in my case and the case of another already-closed issue, was due to one or more of the domains not actually exposing /.well-known/acme-challenge/ over HTTP.

Try reaching those files, the ones created under your public directory, manually with a web browser and fix any permissions or mapping issues and it should work.

I'm going to open another issue about catching that exception and trying to provide more useful information.

[ratkobucic]

@flan
Yes you're right...
I came to same idea and found what's wrong already, and .well-known/acme-challenge/ folder was masked/blocked from wordpress. So, test issuing went well without errors, just going to issue real SSL certificate.
Thanks for pointing out that :)

[will-in-wi]

This has been fixed in version 1.1.7, just released.