| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Ubuntu Linux 20.04.6 |
| Webmin version | 2.101 |
| Usermin version | 2.001 |
| Virtualmin version | 7.8.2 |
| Theme version | 21.07 |
| Package updates | All installed packages are up to date |
| Box name | Game club |
Just attempted to add a new VS and something went wrong!
which inevitably results in
and I guess a whole bundle of other problems.
Oh and found this in the MiniServe error log which might mean something relevant
Thanks Joe for the heads up! It isn’t something I have experienced! I use LE SSL quite a lot on my production server. I would have noticed.
Is there an actual error printed under ERROR - PERL EXECUTION FAILED message?
This error seems completely unrelated.
Also, if you look at /var/log/letsencrypt/letsencrypt.log – do you have anything logged there?
I have run more tests with Let’s Encrypt errors enabled and found one bug when <pre></pre> content is double escaped.
Also, once I got a lock error, i.e.:
2023-10-01 00:02:12,219:WARNING:certbot.display.ops:Hook '--manual-auth-hook' for example.com ran with error output:
[01/Oct/2023:00:02:12 +0300] Failed to lock file /etc/webmin/virtual-server/domains/16568431051281542 after 5 minutes. Last error was : Locked by PID 30112>
Error
-----
Failed to lock file /etc/webmin/virtual-server/domains/16568431051281542 after 5 minutes. Last error was : Locked by PID 3011229 ../web-lib-funcs.pl (line >
-----
However, this is expected (for this particular background job), as there was another process running (upon domain creation time). To be clear, the log with file lock error is background job.
@Jamie, actually, I think there is a bug!
I noticed that the background (scheduled) LE renewal process takes a very very long time, and never finishes with success. It actually just looks like it’s hanging.
When request in the background is happening these are the processes created:
root 3193260 0.0 0.0 2576 888 ? S 01:59 0:00 sh -c cd /bin && (echo A | /bin/letsencrypt certonly --manual -d example\.com -d \*\.example\.com --preferred-challenges=dns --manual-auth-hook /etc/webmin/webmin/letsencrypt-dns.pl --manual-cleanup-hook /etc/webmin/webmin/letsencrypt-cleanup.pl --duplicate --force-renewal --reuse-key --non-interactive --agree-tos --config \/tmp\/\.webmin\/655228_3193217_3_letsencrypt\.cgi --key-type ecdsa --rsa-key-size 2048 --cert-name example\.com 2>&1)
root 3193261 0.0 0.0 2576 108 ? S 01:59 0:00 sh -c cd /bin && (echo A | /bin/letsencrypt certonly --manual -d example\.com -d \*\.example\.com --preferred-challenges=dns --manual-auth-hook /etc/webmin/webmin/letsencrypt-dns.pl --manual-cleanup-hook /etc/webmin/webmin/letsencrypt-cleanup.pl --duplicate --force-renewal --reuse-key --non-interactive --agree-tos --config \/tmp\/\.webmin\/655228_3193217_3_letsencrypt\.cgi --key-type ecdsa --rsa-key-size 2048 --cert-name example\.com 2>&1)
root 3193263 46.2 2.6 95592 53684 ? S 01:59 0:01 /usr/bin/python3 /bin/letsencrypt certonly --manual -d example.com -d *.example.com --preferred-challenges=dns --manual-auth-hook /etc/webmin/webmin/letsencrypt-dns.pl --manual-cleanup-hook /etc/webmin/webmin/letsencrypt-cleanup.pl --duplicate --force-renewal --reuse-key --non-interactive --agree-tos --config /tmp/.webmin/655228_3193217_3_letsencrypt.cgi --key-type ecdsa --rsa-key-size 2048 --cer-name example.com
The LE log looks like this at this time:
root@cloud-1:~# tail -f /var/log/letsencrypt/letsencrypt.log
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/certbot/_internal/client.py", line 496, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/certbot/_internal/auth_handler.py", line 106, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/usr/lib/python3/dist-packages/certbot/_internal/auth_handler.py", line 206, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
2023-10-02 01:42:19,881:ERROR:certbot._internal.log:Some challenges have failed.
2023-10-02 01:59:19,545:DEBUG:certbot._internal.main:certbot version: 2.1.0
2023-10-02 01:59:19,546:DEBUG:certbot._internal.main:Location of certbot entry point: /bin/letsencrypt
2023-10-02 01:59:19,546:DEBUG:certbot._internal.main:Arguments: ['--manual', '-d', 'example.com', '-d', '*.example.com', '--preferred-challenges=dns', '--manual-auth-hook', '/etc/webmin/webmin/letsencrypt-dns.pl', '--manual-cleanup-hook', '/etc/webmin/webmin/letsencrypt-cleanup.pl', '--duplicate', '--force-renewal', '--reuse-key', '--non-interactive', '--agree-tos', '--config', '/tmp/.webmin/655228_3193217_3_letsencrypt.cgi', '--key-type', 'ecdsa', '--rsa-key-size', '2048', '--cert-name', 'example.com']
2023-10-02 01:59:19,546:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2023-10-02 01:59:19,568:DEBUG:certbot._internal.log:Root logging level set at 30
2023-10-02 01:59:19,571:DEBUG:certbot._internal.plugins.selection:Requested authenticator manual and installer None
2023-10-02 01:59:19,572:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * manual
Description: Manual configuration or run your own shell scripts
Interfaces: Authenticator, Plugin
Entry point: manual = certbot._internal.plugins.manual:Authenticator
Initialized: <certbot._internal.plugins.manual.Authenticator object at 0x7fd192533610>
Prep: True
2023-10-02 01:59:19,572:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot._internal.plugins.manual.Authenticator object at 0x7fd192533610> and installer None
2023-10-02 01:59:19,572:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator manual, Installer None
If mentioned background process is running, the SSL request upon a new domain creation time also fails, even though it shouldn’t as it’s a separate domain, e.g.:
What can be the problem? Is this the recent change related to extra locking? Can you please have a closer look?
I think this may be due to the deadlock I found recently when doing DNS-based validation. The fix is here : Fix deadlock when doing DNS-based LE renewals https://forum.virtualmi… · virtualmin/virtualmin-gpl@8596595 · GitHub
No. there wasn’t and unusually the page just hung without option to go elsewhere.
The main menu still functioned though as you can see by my attempt to go get SSL through the menu . It looks like everything went ok up to the point of the error at which point it should have set the port in nginx.
The default page is visible as htp:// but obviously not https:/
the other domains still seem to be unaffected.
under configure nginx the site seems to be listed ok.
I was focusing on the “Perl execution failed” rather than the “Error”
@Jamie just to make it clear. In my case it shouldn’t even be attempting DNS validation. All DNS on this box (and all boxes) are external. So LE should be working web based.
It solves the problem with hanging.
However, there is still an issue when letsencrypt_wild is enabled, which I will address in the separate bug report.
Do you have DNS enabled for the domain?
Sorry about the delay responding (everything has gone mad here today)
no DNS is not enabled for this or any of the domains (don’t need it as it is all on the box provider’s (DO) for this box.
Alright, then Virtualmin shouldn’t try DNS challenge.
Didn’t think it did.
That log above suggested that the web based challenge worked (though perhaps just not applied) I have just tried to load the page in the browser (Chrome) again and am getting
403 Forbidden nginx/1.18.0 (Ubuntu)
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
