I would actually rather prefer active login sessions like you have with other such tools like docker login where you switch between them, but if the token is still valid you don't have to explicitly login. The --cloudron arg is quite some overhead to pass all the time.
The update is already rolled out. We just do it slowly for Nextcloud since in the past, Nextcloud updates caused lots of support requests on our side.
We actually had this some time back, but thought this was only a use-case internal to us. I miss it as well, I will see how we can bring that back in some way.
Good point, I thought this would be triggered by the security update job from ubuntu already, but apparently not.
This would highly depend on the kind of node app. For LAMP there is a http server (apache) running, which serves up a folder tree. This may or may not be the case for a nodejs server, but it is part of the app code itself and there is no such universal concept of htaccess like for apache.
Which nodejs app are you referring to?
You can click the "reset passwort link" button in the user listing. The paperplane icon button.
Is just DKIM and SPF not required or generally that domain not for sending out emails? If the latter is the case, the checks can be disabled by setting the Email Relay to "Disable" in the Outbound tab of the Email settings for this domain.
Can you describe the use-case a bit further? Cloudron already collects logs for each application and addon, as well as the Cloudron related platform components. Generally it is not supported to install other daemons on the side of Cloudron on the same server, since we cannot test such configurations during updates.
FYI all the logs are collected currently as described here https://cloudron.io/documentation/troubleshooting/#logs
@JOduMonT it seems you have just forked the tutorial app and copied things from the upstream netdata Dockerfile. If you actually want to create a Cloudron app package for netdata, then you would have to revisit the package files. For example VOLUME in Dockerfile is not supported, also none of the CloudronManifest.json meta information seems to have been applied to netdata. Also healthcheck is not implemented.
Generally it may be nice to have netdata if it provides useful information and is actually be packaged for Cloudron.
We offer a dev license for upstream projects, which develop apps, which can be packaged for Cloudron.
It should be supported but we don't have any explicit tests for this. Also I am not sure if it was so far verified if the apt based flag for reboot required is working correctly here or if it would still raise the reboot requirement in cases where it might not be required.
Not exactly sure where the misconfiguration lies, but it does not sound too wrong if the BIOS time is UTC and the system is configured with a timezone and adjusts the system time. For simplicity in your case you might as well just set everything to UTC given that you are only 1 hour off. If you want to dive deeper into time management on Linux, you could read through https://wiki.archlinux.org/index.php/System_time#Hardware_clock which explains most of the things as well as instructs you how to keep both in sync.
Ps: The wiki page is for Archlinux, but Ubuntu uses the same tools here.
Our subscriptions are per Cloudron instance, so per server. We might add multihost or some kind of cluster feature in the future, but so far there was no strong focus on this yet.
The main reason is, that there is also no way currently to disable ports by default during installation, so unless manually disabled the app will come up with all those ports being open and unused, while occupying them. We will discuss, if we can put this feature in the next release.
Ah now it makes sense to me, thanks for the explanation. For this indeed we have to wait until port ranges are implemented. Also if I got this correctly, this only applies to the UDP port, not the ServerQuery port (assuming this is for the control entry of the main instance) nor the file transfer port?
Hi @derek sorry for the delayed answer, did you manage to solve this after the TTLs have expired from your attempts?
To understand this further, you usually run multiple Teamspeak server processes with different ts3server.ini (to be able to adjust the ports) and then use the same license file configured in all those config files? Do they have to share the same database or so? If not, wouldn't it work to install multiple Teamspeak app instances on the same Cloudron and then upload the same license to all of them?
@Sidias ah I got it now, I didn't get the slot vs. port thing. I don't see where in Teamspeak you can adjust port ranges, but if you want to run multiple Teamspeak server instances, you can install them alongside each other and during installation assign different ports to them from the Cloudron interface. Each app picks up its assign ports individually. Does that solve your issue?