@Stardenver said in Identify whats causing lags: So the graph showing 200% is 2 cores on 100% each (or something equal like 4 cores on 50% each)? The latter is more probable. If you really want to know, run 'htop' from the command line.

@oj right, best to have another domain added on Cloudron, so you can change things quickly if required. I wasn't aware of all the recent changes, I have to read up. My primary domain is .in ccTld .

Spam filters don't block delivery status messages as they're needed for troubleshooting. If someone else decided to use your address as the From: to spam, there isn't much you can do to stop it, only deal with it (filtering, etc) or turn off delivery to that address until the campaign is over. Forged source headers will always bounce to the source, and yours happens to be deliverable. Sorry.

@nebulon said in Cloudron CLI: ah. The cli is actually not built to run on Cloudron itself, but it would interact with a Cloudron via REST api. Is there a specific use-case where you need it on the server? I want to install the InfluxDB Package, I thought then via Cloudron CLI. So I have to install it on my Client, to install this package.

@Sam_uk I wish they were more transparent on why a site is listed

@d19dotca Yes, that sounds good. We also fixed the logs view now in 7.5 to give a history of past logs. The current one is hard to work with when debugging such things.

@girish silly me sir I had my.domain proxy enabled when I turned off it works

@scooke I am out of ideas then. If you like, you can reach out on support@cloudron.io and we can debug further to see if we can resurrect the app.

@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.