- Package script cleanups
- Automatically restart language tool after n-gram downloads
This is now packaged and the forum section is at https://forum.cloudron.io/category/157/languagetool
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 email@example.com then I can locally fixup your instance
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.
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.
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.
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?
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.
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 now published as unstable. The new forum section is at https://forum.cloudron.io/category/156/libretranslate