pvenode acme account register fails with "Only one Term::ReadLine::Gnu instance is allowed"

D

Daniel Drucker

Active Member
Jun 12, 2020
11
9
43
47
In Proxmox 9.0.5:

Code: 
root@oats1:~# pvenode acme account register default ddrucker@mclean.harvard.edu
Directory endpoints:
0) Let's Encrypt V2 (https://acme-v02.api.letsencrypt.org/directory)
1) Let's Encrypt V2 Staging (https://acme-staging-v02.api.letsencrypt.org/directory)
2) Custom
Enter selection: 2
Enter custom URL: https://acme.sectigo.com/v2/InCommonECCOV

Attempting to fetch Terms of Service from 'https://acme.sectigo.com/v2/InCommonECCOV'..
Terms of Service: https://www.sectigo.com/uploads/files/Certificate-Subscriber-Agreement-2.7-click.pdf
Only one Term::ReadLine::Gnu instance is allowed. at /usr/share/perl5/PVE/CLI/pvenode.pm line 140.
root@oats1:~#
 
  • Like
Reactions: pingoop, ericson2110, shapez0r and 2 others
@Daniel Drucker: you can workaround this problem by calling it with the directory as parameter. In your case pvenode acme account register default ddrucker@mclean.harvard.edu --directory https://acme.sectigo.com/v2/InCommonECCOV

This also works with --directory https://acme-v02.api.letsencrypt.org/directory to use one of the suggested ones.
 
There was now an 'unauthorized' error response from ACME, even when used with --directory. Note: our case is eab-kid and eab-hmac-key and
--directory https://acme.enterprise.sectigo.com
Whatever, just installed certbot and used it with
pvenode cert set /path/to/cert/fullchain.pem /path/to/privatekey/privkey.pem --force --restart
which worked for me

Btw, the original pvenode acme cert order seems doesn't respect the proxmox proxy settings, you have to do an export HTTPS_PROXY= prior to it. Also the GUI button does not respect proxy. So it was anyway not a true acme automation. While in certbot you can

Code: 
cat << EOF > /etc/systemd/system/certbot.service.d/override.conf
[Service]
Environment="http_proxy=http://proxy:port"
Environment="https_proxy=http://proxy:port"
Environment="no_proxy="127.0.0.1,localhost,..""
EOF
 
Last edited:
  • Like
Reactions: pingoop
Facing the same issue as Daniel does.
lookshe said:
@Daniel Drucker: you can workaround this problem by calling it with the directory as parameter. In your case pvenode acme account register default ddrucker@mclean.harvard.edu --directory https://acme.sectigo.com/v2/InCommonECCOV

This also works with --directory https://acme-v02.api.letsencrypt.org/directory to use one of the suggested ones.
Click to expand...


This changes the behaviour, at least to another error:

Code: 
Generating ACME account key..
Registering ACME account..

TASK ERROR: Registration failed: Error: GET to https://acme-staging-v02.api.letsencrypt.org/directory 'acme-ACCOUNT-NAME'-locked command timed out - aborting



The URL is able to be resolved and accessible on the pve host:

Code: 
root@pve01:~# curl https://acme-staging-v02.api.letsencrypt.org/directory
{
  "9Vi9z8_KohI": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "profiles": {
      "classic": "https://letsencrypt.org/docs/profiles#classic",
      "shortlived": "https://letsencrypt.org/docs/profiles#shortlived (not yet generally available)",
      "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
    },
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf",
    "website": "https://letsencrypt.org/docs/staging-environment/"
  },
  "newAccount": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-staging-v02.api.letsencrypt.org/acme/renewal-info",
  "revokeCert": "https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
}
 
  • Like
Reactions: pingoop
Not sure, if it's the same error. but i solved it.

i had the same error:

Only one Term::ReadLine::Gnu instance is allowed.

and i had some other issues as well. i couldn't register my proxmox subscription for example.

After installing Proxmox on a fresh Debian 13 via APT, i skipped the autoremove step. I kept the Perl 5.36 modules.
On another server, i reinstalled them by adding the debian bookworm sources to apt again.

And finally, i had an error in the IPv6 configuration.

after i fixed these things, all errors gone away.
 
Just upgraded to PVE 9.0.10 across all hosts (in part, as the cert process wasn't working under the previous version either), and now we're experiencing the exact same error. Using the --directory switch changes the error to unauthorized, as @shapez0r mentioned. Will test the certbot direct workaround tomorrow.
 
  • Like
Reactions: ericson2110
You must log in or register to reply here.
Top Bottom