Hi,
I discover that there are official OIDC plugin for CryptPad:
https://github.com/cryptpad/sso
Is it possible to have it installed on cloudron bundle ?
Or, at least, have the lib/plugins/ directory available ?
It could be great, mainly to be able to have a private instance that automatically allow SSO user to register.
Thanks !
Cloudron common redis image is vulnerable to critical vulnerability (CVE-2025-49844 - 10 CVSS)
Logs says it's version 7.4.2, fixed version is 7.4.6
Gitlab
Oct 08 12:06:24 13:C 08 Oct 2025 10:06:24.722 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Oct 08 12:06:24 13:C 08 Oct 2025 10:06:24.722 * Redis version=7.4.2, bits=64, commit=00000000, modified=0, pid=13, just started
Oct 08 12:06:24 13:C 08 Oct 2025 10:06:24.722 * Configuration loaded
Oct 08 12:06:24 13:M 08 Oct 2025 10:06:24.722 * monotonic clock: POSIX clock_gettime
Oct 08 12:06:24 13:M 08 Oct 2025 10:06:24.724 # Failed to write PID file: Permission denied
Oct 08 12:06:24 13:M 08 Oct 2025 10:06:24.724 * Running mode=standalone, port=6379.
Oct 08 12:06:24 13:M 08 Oct 2025 10:06:24.725 * Server initialized
Oct 08 12:06:24 13:M 08 Oct 2025 10:06:24.725 * Loading RDB produced by version 7.4.2
Same with N8n:
Oct 08 12:19:46 13:C 08 Oct 2025 10:19:46.483 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Oct 08 12:19:46 13:C 08 Oct 2025 10:19:46.483 * Redis version=7.4.2, bits=64, commit=00000000, modified=0, pid=13, just started
Oct 08 12:19:46 13:C 08 Oct 2025 10:19:46.483 * Configuration loaded
Oct 08 12:19:46 13:M 08 Oct 2025 10:19:46.483 * monotonic clock: POSIX clock_gettime
Oct 08 12:19:46 13:M 08 Oct 2025 10:19:46.485 # Failed to write PID file: Permission denied
Oct 08 12:19:46 13:M 08 Oct 2025 10:19:46.485 * Running mode=standalone, port=6379.
Oct 08 12:19:46 13:M 08 Oct 2025 10:19:46.485 * Server initialized
Oct 08 12:19:46 13:M 08 Oct 2025 10:19:46.486 * Loading RDB produced by version 7.4.2
And all other apps using redis, probably the same redis image is used
{
"version": "8.3.2"
}
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.2 LTS
Release: 24.04
Codename: noble
Manual with ./cloudron-setup
Hi,
As seen in the log, openid-configuration is not working and sending timeout (/.well-known/openid-configuration):
{
"status": "Internal Server Error",
"message": "Response timeout"
}
On some lucky try the page reply correctly.
Also, restarting Docker services in the cloudron front panel unlock the page for few seconds but still re-crash after that.
Rebooting the server doesn't fix the issue.
# cloudron-support --troubleshoot
Vendor: netcup Product: KVM Server
Linux: 6.8.0-110-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: AMD EPYC 9645 96-Core Processor
BIOS pc-i440fx-9.2 CPU @ 2.0GHz x 10
RAM: 24602244KB
Disk: /dev/vda3 796G
[OK] node version is correct
[OK] IPv6 is enabled and public IPv6 address is working
[OK] docker is running
[OK] docker version is correct
[OK] MySQL is running
[OK] netplan is good
[OK] DNS is resolving via systemd-resolved
[OK] unbound is running
[OK] nginx is running
[OK] dashboard cert is valid
[FAIL] Could not load dashboard website with loopback check
and sometimes:
# cloudron-support --troubleshoot
Vendor: netcup Product: KVM Server
Linux: 6.8.0-110-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: AMD EPYC 9645 96-Core Processor
BIOS pc-i440fx-9.2 CPU @ 2.0GHz x 10
RAM: 24602244KB
Disk: /dev/vda3 796G
[OK] node version is correct
[OK] IPv6 is enabled and public IPv6 address is working
[OK] docker is running
[OK] docker version is correct
[OK] MySQL is running
[OK] netplan is good
[OK] DNS is resolving via systemd-resolved
[OK] unbound is running
[OK] nginx is running
[OK] dashboard cert is valid
[OK] dashboard is reachable via loopback
[OK] No pending database migrations
[OK] Service 'mysql' is running and healthy
[OK] Service 'postgresql' is running and healthy
[WARN] Service 'mongodb' is not running (may be lazy-stopped)
[OK] Service 'mail' is running and healthy
[OK] Service 'graphite' is running and healthy
[OK] Service 'sftp' is running and healthy
[OK] box v9.1.6 is running
[FAIL] Could not load dashboard domain.
Error /home/yellowtent/platformdata/logs/box.log:
2026-04-17T09:55:16.954Z oidcserver: find: error getting client null
{
path: '/well-known-handler/openid-configuration',
status: 500,
error: ServerError [ServiceUnavailableError]: Response timeout
at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/connect-timeout/index.js:84:8)
at IncomingMessage.emit (node:events:508:28)
at Timeout._onTimeout (/home/yellowtent/box/node_modules/connect-timeout/index.js:49:11)
at listOnTimeout (node:internal/timers:605:17)
at process.processTimers (node:internal/timers:541:7) {
--
}
}
No it cannot be some spaces, because the original data come from my phone contact app and it's the same label, synchronized by davx5 on radicale. It can still be some bug at the radicale export.
"This leaves the question what kind of vcard field in your case was synced as labels via davx? Is it maybe possible to that you can share one of those vcards here (replacing sensitive data)?"
I can share to you one of the vcard if you still want to work on this later...but as i heavily use the label feature if it's removed i'll go back with radicale. The great web interface with label handled was the reason of my move.
DavX5 ask for the configuration for contact group / contact label, with "groups are per-contact categories" (no separate vCard per group), the android label was working on my contact app and on android.
MacOs contacts use the other way for example.
Here is Anonymised file (can't upload): https://file.cloudron-demo.com/Anonymised.vcf
Imported successfully on https://contacts.cloudron-demo.com/
All links here are now dead.
Also, repositories for official cloudron apps are also inaccessible, is this permanent ?
It's great when packaging custom apps to see real example you already done, not only example package.
Is there a way to get access to there repositories again (read-only) ?
Hi,
An automatic upgrade happened this night on our server and all DNS queries result in empty response from systemd-resolved.
Here a part of the box.log where we saw the first error:
2024-08-10T01:33:35.165Z box:apphealthmonitor app health: 24 running / 2 stopped / 0 unresponsive
2024-08-10T01:33:36.851Z box:box Received SIGTERM. Shutting down.
2024-08-10T01:33:36.858Z box:platform uninitializing platform
2024-08-10T01:33:36.859Z box:shell startTask: /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 12905 /home/yellowtent/platformdata/logs/tasks/12905.log 15 1024 errored BoxError: startTask exited with code null signal SIGTERM
at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:110:19)
at ChildProcess.emit (node:events:513:28)
at ChildProcess._handle.onexit (node:internal/child_process:291:12) {
reason: 'Shell Error',
details: {},
code: null,
signal: 'SIGTERM'
}
2024-08-10T01:33:36.934Z box:tasks startTask: 12905 completed with code null
2024-08-10T01:33:36.937Z box:tasks setCompleted - 12905: {"error":{"message":"Task 12905 crashed with code null","code":"crashed"}}
2024-08-10T01:33:36.937Z box:tasks update 12905: {"percent":100,"error":{"message":"Task 12905 crashed with code null","code":"crashed"}}
2024-08-10T01:33:36.938Z box:platform onDeactivated: stopping post activation services
2024-08-10T01:33:36.939Z box:tasks stopAllTasks: stopping all tasks
2024-08-10T01:33:36.940Z box:shell stopTask /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2024-08-10T01:33:36.952Z box:locker Released : box_update
2024-08-10T01:33:36.952Z box:updater Update failed with error. { message: 'Task 12905 crashed with code null', code: 'crashed' }
2024-08-10T01:33:36.953Z box:tasks startTask: 12905 done. error: { message: 'Task 12905 crashed with code null', code: 'crashed' }
2024-08-10T01:35:10.561Z box:server ==========================================
2024-08-10T01:35:10.562Z box:server Cloudron 8.0.3
2024-08-10T01:35:10.562Z box:server ==========================================
2024-08-10T01:35:10.562Z box:platform initialize: start platform
2024-08-10T01:35:10.902Z box:tasks stopAllTasks: stopping all tasks
2024-08-10T01:35:10.902Z box:shell stopTask /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
sudo: unable to resolve host my: Temporary failure in name resolution
All tasks stopped
2024-08-10T01:35:11.141Z box:reverseproxy writeDashboardConfig: writing dashboard config for a38.fr
2024-08-10T01:35:11.158Z box:shell isOscpEnabled execArgs: openssl ["x509","-in","/home/yellowtent/platformdata/nginx/cert/_.a38.fr.cert","-noout","-ocsp_uri"]
2024-08-10T01:35:11.179Z box:shell reload /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx
sudo: unable to resolve host my: Temporary failure in name resolution
nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "e5.o.lencr.org" in the certificate "/home/yellowtent/platformdata/nginx/cert/_.a38.fr.cert"
nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "e5.o.lencr.org" in the certificate "/home/yellowtent/platformdata/nginx/cert/a38.fr.cert"
nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "e5.o.lencr.org" in the certificate "/home/yellowtent/platformdata/nginx/cert/_.a38.fr.cert"
nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "e5.o.lencr.org" in the certificate "/home/yellowtent/platformdata/nginx/cert/_.a38.fr.cert"
dig response:
$ dig api.cloudron.io
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> api.cloudron.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12668
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api.cloudron.io. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Aug 10 15:56:07 UTC 2024
;; MSG SIZE rcvd: 44
All apps were in error state and i successfully started them all with write api.cloudron.io in host file and retry configure task in cloudron panel.
Unfortunately, this is only temporary fix as dns issue is still there and app store for example is still unavailable (so i commented out this fix).
Hi @nebulon ,
Thanks for investigation, but I'm sorry i don't think it's the explanation.
On friday we were able to reproduce the behavior just by going to the "/.well-known/openid-configuration" from our browsers but also from the server itself with wget, excluding any external network issue.
Your troubleshooting report tool also report same issue with some other path, the openid path is only the best one to see the issue.
The explanation of occasional timeouts is probably because the server has not many users and many apps do not require re-login or other path that has issue.
Finally, even if heavy load is the explanation, we do not change our habits, so were does it come from ? How to avoid that ? All the server load statistics are very good, and i made some test few minutes ago the url just always timeout even locally with wget.
edit: # wget http://127.0.0.1/ is timeouting too