@lukas you posted there yesterday.

The DuckDNS.org is the most popular way to get a domain for free and it's extremely important for selfhosting. From what I saw in sources the Cloudron has own implementation of the ACME DNS challenge. The problem is that each DNS provider has own API incompatible with others. The Sandstorm.io instead uses the library https://github.com/therootcompany/acme.js which was also developed for a selfhosting project. The library has support of many providers including the DuckDNS. As an alternative solution may be acme.sh which is not in JS but in plain shell instead. It has support of probably all possible DNS providers. Interesting that the Sandstorm doesn't support setting of a custom domain but instead use it's own DDNS service sandcats.io The service is not that good and doesn't support setting of TXT or MX records. I'm working now on writing a DDNS server that can be deployed https://github.com/yurt-page/go-ddnsd. There is already one existing called https://github.com/nsupdate-info/nsupdate.info which supports users registration. But I wish to make something more lightweight and simpler with autoregistration and I'll continue later. You guys can try to deploy the DDNS server and autoregister new cloudron installs and give a free subdomains. This will help a lot for selfhosters.

@jayonrails whoops, didn't notice!

@jayonrails We just started on it, so will take a month probably atleast.

I have complained here - https://github.com/aws/aws-sdk-js/issues/4354#issuecomment-1544608887 . I don't understand why they do this, makes no sense. Especially, the v3 js sdk is not even ready.

@mathieuepitech Ah, I didn't realize you were on a older Cloudron version. Indeed, du.py is now gone.

on page refresh, the variable was enumerated.

There was an error in the logs about some keys that resembled another post here. The recommendation was to delete two files (don't remember which ones) and after doing so, the installation went through and after that I was able to update. The issue has been resolved.

Link to docs for future reference - https://docs.cloudron.io/user-management/#endpoints

Strange indeed, but I blocked the VPS Port 25. Whilst blocked, I restarted Kuma and Tiny but to no avail. All up and running now with 25 unblocked.

@girish Are you saying that the user manually updated the node version, which I assume is the one that Cloudron that installed, and it installed that version so that it works, but then had this issue because they did something that they aren't advised to do (which is manually update)??? It might be worthwhile to highlight the fact (on the homepage or in the install instructions) that Cloudron manages the VPS for the user so that new users don't keep doing this, _running apt-get update on their own!

This brings up a good point.. for the power users out there, there could be an un/official guide on how to mindfully and safely run other services alongside, provided Cloudron services take priority. It would certainly make things more efficient and less blackbox. No support required, yet also a useful link to point folks to who will do it anyway. Many birds, one stone.

@warg Yes, that crash happens when the server becomes unresponsive . So, the code restarts itself. If it happens often, it's something to investigate. But the root cause can be network or VM related.

And I have deleted Jitsi for the moment. Not being used much currently. Will reinstall when I have time to get my head securing it. So will close this now.

@BrutalBirdie great suggestion, thanks for that!

@girish Yes

@TheNils If you write to us on support@cloudron, I can debug further. It's not clear what's going on.

@DeBossNow The content is based on the app. In the docs screenshot, it's an emby installaton. Where in yours it looks like it is mastodon app. What is shows is just the contents of the /app/data directory. Only the files you see above are editable. If you want to see application files (source files), you have to use the web terminal - https://docs.cloudron.io/apps/#web-terminal . Note that application files are readonly and cannot be changed.

@DeBossNow I am glad you got it resolved, but just to clarify: The MX record is for incoming email. It needs to be set to any domain name that resolves to your server, i.e. has a valid A record. If both my.currentdoain.de and currentdomain.de resolve then you can use either for incoming mail. The mismatch was not with the MX record but between the mailserver domain set in Cloudron and the PTR record of the server. At no point did I or anyone else tell you to change the MX record, and no, the PTR error had nothing to with the MX record. I can therefore only assume that you interpreted MX as being something it is not. For outgoing mail you need a valid PTR record that matches the mailserver domain. You also need a valid SPF record and a valid DKIM entry. Because you set up Cloudron via the Linode app you have presumably told Cloudron to use Linode DNS, which is why it is updating / overriding certain settings. If you do not want it to do that you need to set DNS to manual for the resepctive domain(s). The bottom line is: The PTR record and mailserver domain have to match. Where you make the changes depends solely on the domain you want to use for email, i.e. where the entry needed updating to match. Btw, I stated every time that you needed to check / update the mail domain in Cloudron, not in the Linode dashboard.