Undefined subroutine &main::restart_zone

After updating to Virtualmin 6.08, we're receiving the following error when attempting to generate a Let's Encrypt certificate (either while creating a new virtual server or, when that fails, going in and trying to generate it again for the same virtual server). Renewing existing certificates does not seem to be affected at this time.

Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl manual-auth-hook command "/etc/webmin/webmin/letsencrypt-dns.pl" returned error code 1 Error output from manual-auth-hook command letsencrypt-dns.pl: Undefined subroutine &main::restart_zone called at /usr/libexec/webmin/webmin/letsencrypt-dns.pl line 47.

Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl manual-auth-hook command "/etc/webmin/webmin/letsencrypt-dns.pl" returned error code 1 Error output from manual-auth-hook command letsencrypt-dns.pl: Undefined subroutine &main::restart_zone called at /usr/libexec/webmin/webmin/letsencrypt-dns.pl line 47.

Status: 
Active

Comments

Title: Undefined subroutine &main:;restart_zone » Undefined subroutine &main::restart_zone
Assigned: Unassigned »

Howdy -- thanks for your report!

I'm passing this to Jamie for comment.

Status:
Fixed (pending)
»
Active

Hi Jamie, and thanks for your prompt response to this issue. I applied the two files from the commit you linked in your post (letsencrypt-cleanup.pl and letsencrypt-dns.pl) to /usr/libexec/webmin/webmin on my system and restarted Webmin, but now get the following error when I try to create a new virtual server with SSL and Let's Encrypt enabled:

Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl manual-auth-hook command "/etc/webmin/webmin/letsencrypt-dns.pl" returned error code 2 Error output from manual-auth-hook command letsencrypt-dns.pl: Failed to run /usr/libexec/webmin/webmin/letsencrypt-dns.pl : No such file or directory at /etc/webmin/webmin/letsencrypt-dns.pl line 12.

Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl manual-auth-hook command "/etc/webmin/webmin/letsencrypt-dns.pl" returned error code 2 Error output from manual-auth-hook command letsencrypt-dns.pl: Failed to run /usr/libexec/webmin/webmin/letsencrypt-dns.pl : No such file or directory at /etc/webmin/webmin/letsencrypt-dns.pl line 12.

Note that if I then go into Server Configuration > SSL Certificate > Let's Encrypt on that same virtual server, the generation process works flawlessly. I have confirmed that both /usr/libexec/webmin/webmin/letsencrypt-cleanup.pl and /usr/libexec/webmin/webmin/letsencrypt-dns.pl do exist, have the new code in them from the Github commit, and have permissions set to 755.

Make sure that /usr/libexec/webmin/webmin/letsencrypt-dns.pl and the other file start with #!/usr/bin/perl

They actually both (letsencrypt-cleanup.pl and letsencrypt-dns.pl) start with:

!/usr/local/bin/perl

But /usr/local/bin/perl does not exist on my system. Instead, it looks like it's found in /usr/bin/perl (according to the "which" command). Could this be the problem? I didn't change any lines in the file, I just copied and pasted the patched files from the Github commit.

Understood, that's what Jamie means above... you'd need to change the path to point to the Perl binary in those files.

It's part of our build process to update the Perl path for the OS in question, but if the file is being manually pulled from git like the case here, the path would just need to be updated at the top of those files.

I changed the path at the top of the two files from /usr/local/bin/perl to /usr/bin/perl (the correct one for my system) and that solved that particular problem but not the issue as a whole. I am no longer getting specific errors from running the commands as I was yesterday, but the Let's Encrypt certificate is still not issuing when a virtual server is created. If I go back into Virtualmin after the server is created, go to Server Configuration > SSL Certificate > Let's Encrypt and try to generate it that way, it works just fine. But before Virtualmin 6.08, a Let's Encrypt certificate for a domain would be issued successfully during the virtual server creation process.

Here is the full log of what happens as Virtualmin tries to request an SSL certificate during virtual server creation (this is a top-levle server even though it looks like a subserver):

Requesting a certificate for vm-test86.jemcdev.com, www.vm-test86.jemcdev.com from Let's Encrypt .. .. request failed : Web-based validation failed :

Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org Obtaining a new certificate Performing the following challenges: http-01 challenge for vm-test86.jemcdev.com http-01 challenge for www.vm-test86.jemcdev.com Using the webroot path /home/vm-test86/site for all unmatched domains. Waiting for verification... Challenge failed for domain vm-test86.jemcdev.com Challenge failed for domain www.vm-test86.jemcdev.com http-01 challenge for vm-test86.jemcdev.com http-01 challenge for www.vm-test86.jemcdev.com Cleaning up challenges Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server:

Domain: vm-test86.jemcdev.com Type: unauthorized Detail: Invalid response from https://vm-test86.jemcdev.com/.well-known/acme-challenge/EbJIOBRQxcngHk_... [45.79.193.237]: "\n\n404 Not Found\n\n

Not Found

\n

<

p"

Domain: www.vm-test86.jemcdev.com Type: unauthorized Detail: Invalid response from https://www.vm-test86.jemcdev.com/.well-known/acme-challenge/dYKDbR4j_eq... [45.79.193.237]: "\n\n404 Not Found\n\n

Not Found

\n<p"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. DNS-based validation failed : Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator manual, Installer None Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org Obtaining a new certificate Performing the following challenges: dns-01 challenge for vm-test86.jemcdev.com dns-01 challenge for www.vm-test86.jemcdev.com Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl Waiting for verification... Challenge failed for domain vm-test86.jemcdev.com Challenge failed for domain www.vm-test86.jemcdev.com dns-01 challenge for vm-test86.jemcdev.com dns-01 challenge for www.vm-test86.jemcdev.com Cleaning up challenges Running manual-cleanup-hook command: /etc/webmin/webmin/letsencrypt-cleanup.pl Running manual-cleanup-hook command: /etc/webmin/webmin/letsencrypt-cleanup.pl Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server:

Domain: vm-test86.jemcdev.com Type: dns Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.vm-test86.jemcdev.com

Domain: www.vm-test86.jemcdev.com Type: dns Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.vm-test86.jemcdev.com

Could be this not 100% ready while   Installer None Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org Obtaining a new certificate Performing the following challenges: dns-01 challenge for vm-test86.jemcdev.com dns-01 challenge

https://www.virtualmin.com/comment/818433#comment-818433

only pointing out. ;)

Maybe but the DNS was ready by the time Virtualmin requested the certificate, because it creates the DNS zone (and restarts the DNS server) before it gets to the certificate part. Also, this worked flawlessly before Virtualmin 6.08 came out last week.

Oh, thanks for spotting that, I didn't even know they had moved from v1 to v2. I just find it odd this works for renewing existing certificates on existing virtual servers but not for creating new ones when a virtual server is created; after some testing I realized I have to wait 2 minutes or more after the completion of the virtual server creation process before I can generate a certificate without getting an error. Before Virtualmin 6.08 this process happened automatically during virtual server creation with no errors.

don't know if the pre-check option for the LE script can help with that. ( could be helpfull to prevent the limit part) Sorry also only pointing this out no knowledge from scripts.

Only that v1 for new certs could have problems, renew fasing out at LE for v1 is later but soon, for new LE certs is v1 already EOL and fased out partly.

Handy to look to https://letsencrypt.status.io/

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/2 scroll down here for more

Any update on this from the Virtualmin team? I am still unable to generate SSL certificates automatically at virtual server creation time, but if I wait anywhere between 1 to 10 minutes (and restart HTTPD which I never had to do before now to get certificates to be generated at creation time), Virtualmin will generate them without problems. This doesn't always work though, sometimes even when I wait a few minutes and run the generate-letsencrypt-cert command from the CLI it still doesn't work. I can provide login access to my server if this would be easier to troubleshoot that way.

I asked Jamie for his input on this one, we'll see what he has to say!

Thanks. Let me know if you need further details, login access for additional troubleshooting, etc.

Do you have the official certbot let's encrypt client installed? That should resolve the issue of incompatibility with the built-in let's encrypt client.

Yeah, I think it's already installed. Doing rpm -qa | grep "certbot" on my system returns this:

certbot-0.39.0-1.el7.noarch python2-certbot-0.39.0-1.el7.noarch

Ok .. any way we can get login access to this system?

Sure. I've enabled remote access in Virtualmin that will remain active until Sunday, october 27. Virtualmin stated an e-mail with details has been sent to remote@virtualmin.com.

Thanks! What's the IP of your system?

Jamie,

Were you able to gain remote access to my system before the keys expired yesterday evening? If not I can re-enable the remote access through Virtualmin.

Happy Halloween! Any update on this issue from the Virtualmin guys?

Actually I'm still unable to SSH into your system - it doesn't accept my SSH key.

Sorry about that Jamie. I've re-enabled Virtualmin remote logins, this time indefinitely, to give you another opportunity to log into the system. Also I had to change the SSH port to 2222 (so I could run a Git-based SSH server on 22) so please use that port when connecting.

Any update on this? I get the same error now on a brand-new Virtualmin 6.08 installation I set up on a new server (it's GPL not Pro though for now).