[0.3.0]
- Package script cleanups
- Automatically restart language tool after n-gram downloads
[0.3.0]
This is now packaged and the forum section is at https://forum.cloudron.io/category/157/languagetool
[1.13.0]
You can use this thread to track updates to the LanguageTool package.
Please open issues in a separate topic instead of replying here.
[1.30.4]
[1.10.16]
[2.4.0]
[1.5.2]
[1.6.57]
[1.38.3]
[1.30.3]
[2.35.2]
[1.10.15]
Oh right, this is the whole box backup listing, not the apps backup listing. Looking at the code, that Cloudron level section needs the same fix
Will do a fix now and if you want enable remote SSH support for us and send a mail with your dashboard domain to support@cloudron.io then I can locally fixup your instance
[4.32.0]
The issue which was fixed was that the listing only showed a maximum of 25 backups. Can you maybe refresh the browser cache for the dashboard, just to rule out that you still see the old code?
Further how many backups do you see now?
I have enabled this also with our cloudron mastodon instance now and it works mostly. For some reason mastodon does not always show the translate button and sometimes it also shows it for english posts, which then results in a 503 response error, since libretranslate got the request to translate from en -> en which is wrong.
Just sharing this here, to set expectations.
@LoudLemur that is indeed strange, Cloudron only reports a running state if the healthcheck succeeds which for libretranslate means that the api and frontend server is up and running.
@LoudLemur actually all language models are currently part of the image itself, so the initial startup is faster. Also half the image size is actually the app itself, mostly python modules like torch. The goal for the package was basically to have an app which needs no further configuration and has everything included, with the tradeoff of disk space essentially.
[1.2.3]
[1.10.2]
To add some more context, this is about essentially enabling the proxyAuth
addon to the app proxy app with optionalSso
set in the manifest. This is implemented by now, pending a Cloudron and proxy app release.
thanks for sharing that process. Was there anything which requires a fix on the packaging side?
Indeed the app does not support 2fa yet, but since the frontend at least is developed by us at https://git.cloudron.io/cloudron/openvpn-app we can add this.
This then appears to be an issue on the receiving email server. Most probably issue is, that the receiving server marks the emails as spam. For new servers it sometimes takes some longer time for the IP address reputation to go up.
@imc67 do you have any plugin installed which may use websockets? Those are long-lived, so each websocket connection will use one request worker.
Can you check the email event log and mail queue, if the app has sent the email but there was a delivery issue? https://docs.cloudron.io/email/#event-log
The latest package release has this now set to 1 year expiration.
The reason why a custom setting didn't work, was that all configs are dynamically generated during app startup. Since that config file does not really have much useful options to be set by the user, I decided to just fixup the token expiration instead of trying to merging user and system settings on every startup.
Just to be sure, have you installed Guacamole via Cloudron on Linode or directly on the server? Asking since this is a Cloudron related forum. On Cloudron you can see the app logs via the logviewer from the dashboard.
[1.5.1]
Your initial telnet
command was the right approach to test basic connectivity. So most likely there is some firewall setup blocking port 222 on your server. Is there some other external firewall or route based access control setup in contabo for port 222?
All such addons inject env variables into the app. So you can open a webterminal into the app and run env
to see all those. The addon docs page lists all of them at https://docs.cloudron.io/packaging/addons/#turn
[4.31.0]
I created an upstream issue due to lack of ideas on how to debug this further https://github.com/lukevella/rallly/issues/421
This is solved with package v0.3.0 now. @vladimir-d rewrote the initial setup altogether for that.
[1.8.20]
[1.0.0]
[1.28.4]
[1.12.5]
[1.26.2]
Just to be sure, have you tried the setup again and it fails the same way? Also maybe give the server some time to startup completely before running the Cloudron setup script. Sometimes the cloud-init scripts from the provider are still running while SSH already works.
[1.13.5]
[1.5.10]
[1.10.14]
Looks like their Ubuntu 22 image requires some custom fixes then. Do you see further errors in /var/log/dpkg.log
to get more information on what exactly failed?
This is published as unstable. Forum section is at https://forum.cloudron.io/category/154/rallly
This is now published as unstable. The new forum section is at https://forum.cloudron.io/category/156/libretranslate
@robi I agree it is useful, maybe you can add this as a feature request though, as currently it is explicitly not supported.
@Supaiku have you tried to add a volume in Cloudron with the existing mountpoint option? The symlink as such will not work as Cloudron will resolve the mount point directly