You are here
BFF - Sun, 2025/04/27 - 23:02
Hello,
i'm getting this error here:
Can you help me? I'm using Turnkey-nextcloud iso, debian bookworm, updated to the last version.
i'm getting this error here:
[2025-04-27 21:55:33] dehydrated-wrapper: FATAL: Dehydrated not installed, or not in the $PATH
tee: '': No such file or directory
Failed to mangle name: Invalid argument
Failed to expand names: Invalid argument
tee: '': No such file or directory
Can you help me? I'm using Turnkey-nextcloud iso, debian bookworm, updated to the last version.
Forum:
Tags:
Solved
apt-get install dehydrated -yHi BFF, glad you resolved it
Hi BFF, I'm glad that you resolved it, but I wouldn't expect that to occur as Dehydrated should be pre-installed.
Could you confirm exactly which TurnKey version? If unsure, run:
Also, is this a clean install, or one you've been running for a while? Anything else you can share that might help me understand how this occurred would be appreciated.
Sure
So... I will describe in more details what happened.
My vm is an old one that i use, so i did make some changes on the way
I was trying to install a dev version of curl with http3 functionality. So had to remove Curl, which removed with it the dehydrated package. This caused to brake the confconsole renew certificate. I undid the changes, reinstalled everything but i wasn't suscefull.
The thing is that now i'm getting this error when trying to renew the certificate:
What do you think?
Thanks for the extra info
It looks like it's choking on the version of openssl it's finding in /usr/local/bin:
My guess is that is left from your newer curl install - but fails because there are missing components (the shared objects noted).
You could just remove that executable from /usr/local/bin - i.e.:
Or I have an updated version of the cron job with a hardcoded path to the system openssl - which should work without needing to change anything else.
If you'd like to test the updated cron job, it'd be great if you could leave the /usr/local/bin/openssl where it is and report back. You can delete it if you'd like after we're sure the new cron job works.
If you are up for testing the updated cron job, you can "install" it like this:
Let me know either way.
I ran this:
I ran this:
And solved this issue
Now i have the following:
[2025-04-28 12:51:56] dehydrated-wrapper: INFO: started # INFO: Using main config file /etc/dehydrated/confconsole.config + Account already registered! [2025-04-28 12:51:58] dehydrated-wrapper: INFO: found apache2 listening on port 80 [2025-04-28 12:51:58] dehydrated-wrapper: INFO: stopping apache2 [2025-04-28 12:51:59] dehydrated-wrapper: INFO: running dehydrated # INFO: Using main config file /etc/dehydrated/confconsole.config Processing myexampledomain + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Apr 29 21:33:48 2025 GMT (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 1 authorizations URLs from the CA + Handling authorization for myexampledomain + 1 pending challenge(s) + Deploying challenge tokens... [2025-04-28 12:52:06] confconsole.hook.sh: INFO: Deploying challenge for myexampledomain [2025-04-28 12:52:06] confconsole.hook.sh: INFO: Serving /var/lib/dehydrated/acme-challenges/rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE on http://myexampledomain/.well-known/acme-challenge/rtQ> + Responding to challenge for myexampledomain authorization... + Cleaning challenge tokens... [2025-04-28 12:52:19] confconsole.hook.sh: INFO: Clean challenge for myexampledomain + Challenge validation has failed :( ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01" ["url"] "http://acme-v02.api.letsencrypt.org/acme/chall/xxxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx" ["status"] "invalid" ["validated"] "2025-04-28T10:52:07Z" ["error","type"] "urn:ietf:params:acme:error:connection" ["error","detail"] "xxx.xx.xxx.xxx: Fetching http://myexampledomain/.well-known/acme-challenge/rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE: Timeout during connect (likely firewall problem)" ["error","status"] 400 ["error"] {"type":"urn:ietf:params:acme:error:connection","detail":"xxx.xx.xxx.xxx: Fetching http://myexampledomain/.well-known/acme-challenge/rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE:> ["token"] "rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE" ["validationRecord",0,"url"] "http://myexampledomain/.well-known/acme-challenge/rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE" ["validationRecord",0,"hostname"] "myexampledomain" ["validationRecord",0,"port"] "80" ["validationRecord",0,"addressesResolved",0] "xxx.xx.xxx.xxx" ["validationRecord",0,"addressesResolved"] ["xxx.xx.xxx.xxx"] ["validationRecord",0,"addressUsed"] "xxx.xx.xxx.xxx" ["validationRecord",0] {"url":"http://myexampledomain/.well-known/acme-challenge/rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE","hostname":"myexampledomain","port":"80","addresse> ["validationRecord"] [{"url":"http://myexampledomain/.well-known/acme-challenge/rtQLk_asZjbAbS0mmFt9F9aKFc2c73aR0fHtsECtE","hostname":"myexampledomain","port":"80","address> [2025-04-28 12:52:19] dehydrated-wrapper: FATAL: dehydrated exited with a non-zero exit code. [2025-04-28 12:52:19] dehydrated-wrapper: WARNING: Python is still listening on port 80 [2025-04-28 12:52:19] dehydrated-wrapper: INFO: attempting to kill add-water server [2025-04-28 12:52:19] dehydrated-wrapper: INFO: Cleaning backup cert & key [2025-04-28 12:52:19] dehydrated-wrapper: INFO: (Re)starting apache2 [2025-04-28 12:52:19] dehydrated-wrapper: INFO: (Re)starting webmin.service [2025-04-28 12:52:19] dehydrated-wrapper: WARNING: Check today's previous log entries for details of error.I found a solution
So i gave up on my CT and started all over!
:)
I did the mariadb raw backup, update till the top version of my nextcloud, distro and php...
it took some time but i got everything up and running.
My setup is quite simple so I had no snapshot of my CT. But since I like to test some configs from time to time I'm kind rethinking it.
Probably a good idea...
A new container is probably a good idea. And I certainly recommend some sort of backup and/or snapshot before doing anything of substance. :)
FYI linking the shared libraries from /usr/local/lib64 (as ldconfig would have done) is probably not the best idea - except on a test server. It seems like that resolved the immediate issue of the http cert not updating, but I suspect that it may have bitten you down the track somewhere - and would likely be tricky to diagnose.
Regardless, glad you got it all worked out.
Add new comment