5ad45b4d-0d0f-4163-93b6-65aca588f2d4-image.png

I seem to be having a similar issue. None of the apps in cloudron are using enough cpu to even show up here, but I am constantly needing to reboot the cloudron vm to get the cpu usage to drop back down to normal levels.

Not sure if you can tell from the graph, but I've needed to reboot it 3 times in the last month because apps become unresponsive whenever this happens.

htop won't help now because it was just rebooted yesterday and everything seems to be running smoothly.
Does anyone have any suggestions on how to find out why this is happening, or how to find out the cause?

@Fabix thanks. Strange stuff... I will put it in our docs that we only support Robot.

@Recliner2042 It needs to write to DNS . You can read more at https://letsencrypt.org/docs/challenge-types/ (dns-01).

Hi @Thedurancode,

the way apps are designed on Cloudron it is not possible to change any of the actual application code (and therefore you get the file permission errors). Instead you will either need to wait until Nextcloud 26 is generally available (you can check this post to check for the latest release) or you would need to fork the app code and perform the update there. The latter is easy to do if you are familar with Cloudron app development, but not really recommended for beginners (ihmo).

@girish oh, ok then sorry for this!

@Kubernetes good catch, seems like a regression. We see this in our Cloudron too...

@roofboard said in Chat woot cannot uninstall after breaking the backup system.:

Mar 30 20:19:30 box:services Backing up postgresql
Mar 30 20:29:30 box:services pipeRequestToFile: timeout - connect or post-connect idle timeout

It seems somehow postgresql was not having a happy time. Maybe give it a bit more memory (Services -> PostgreSQL -> increase memory limit). The reboot probably just freed up some memory.

Maybe MySQL has already fixed this. When you guys have time, please update to 7.4.0 and let's check the situation there. Atleast, on our servers, the issue is not reproducible (not even with 7.3.).

Also, in Cloudron 7.3.x, all the addons/services are still using the old base image (3.2.0) but the apps have all been updated now to use the new base image (4.0.0) . In 7.4, all the addon docker images are updated to 4.0.0. You will see some space savings after the update.

@girish ok got it. Thank you.

@whitespace ask @BrutalBirdie about his magic with Zabbix. Perhaps this is an option for your use case.

@affinity yes, so in coming releases, we will have a checksum to verify backups. Hopefully, this is caught sooner and not just when trying to restore.

@girish said in Cloudron reports blacklisting (by mistake?):

@nichu42 Strange, I have tried this on multiple servers now and the same spamhaus servers says it's not listed. But on your server, it says it is listed. Crazy. Just to rule out some obvious caching issues, can you please run those host commands again after systemctl restart unbound ?

Done.
Before the restart:

2023-03-28T07:23:37.382Z box:mail checkRblStatus: blueplanet.social (ip: 88.64.0.128) is in the blacklist of {"name":"Composite Blocking List","dns":"cbl.abuseat.org","site":"http://www.abuseat.org"} 2023-03-28T07:23:37.405Z box:mail checkRblStatus: blueplanet.social (error: queryTxt ENOTFOUND 88.64.0.128.cbl.abuseat.org) (txtRecords: undefined) 2023-03-28T07:23:37.429Z box:mail checkRblStatus: 42bit.io (ip: 88.64.0.128) is in the blacklist of {"name":"Composite Blocking List","dns":"cbl.abuseat.org","site":"http://www.abuseat.org"} 2023-03-28T07:23:37.430Z box:mail checkRblStatus: 42bit.io (error: queryTxt ENOTFOUND 88.64.0.128.cbl.abuseat.org) (txtRecords: undefined) 2023-03-28T07:23:38.235Z box:mail checkRblStatus: blueplanet.social (ip: 128.0.64.88) blacklistedServers: [{"name":"Composite Blocking List","dns":"cbl.abuseat.org","site":"http://www.abuseat.org","txtRecords":"No txt record"}]) 2023-03-28T07:23:38.241Z box:mail checkRblStatus: 42bit.io (ip: 128.0.64.88) blacklistedServers: [{"name":"Composite Blocking List","dns":"cbl.abuseat.org","site":"http://www.abuseat.org","txtRecords":"No txt record"}]) Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: 88.64.0.128.zen.spamhaus.org has address 127.255.255.254 Host 88.64.0.128.zen.spamhaus.org not found: 3(NXDOMAIN)

After the unbound restart (ALMOST identical):

2023-03-28T07:25:51.522Z box:mail checkRblStatus: blueplanet.social (ip: 88.64.0.128) is in the blacklist of {"name":"SpamHaus Zen","dns":"zen.spamhaus.org","site":"http://spamhaus.org"} 2023-03-28T07:25:51.543Z box:mail checkRblStatus: blueplanet.social (error: null) (txtRecords: [["Error: open resolver; https://www.spamhaus.org/returnc/pub/2400:cb00:65:1024::a29e:8507"]]) 2023-03-28T07:25:51.584Z box:mail checkRblStatus: blueplanet.social (ip: 128.0.64.88) blacklistedServers: [{"name":"SpamHaus Zen","dns":"zen.spamhaus.org","site":"http://spamhaus.org","txtRecords":["Error: open resolver; https://www.spamhaus.org/returnc/pub/2400:cb00:65:1024::a29e:8507"]}]) 2023-03-28T07:25:51.586Z box:mail checkRblStatus: 42bit.io (ip: 88.64.0.128) is in the blacklist of {"name":"SpamHaus Zen","dns":"zen.spamhaus.org","site":"http://spamhaus.org"} 2023-03-28T07:25:51.587Z box:mail checkRblStatus: 42bit.io (error: null) (txtRecords: [["Error: open resolver; https://www.spamhaus.org/returnc/pub/2400:cb00:65:1024::a29e:8507"]]) 2023-03-28T07:25:51.588Z box:mail checkRblStatus: 42bit.io (ip: 128.0.64.88) blacklistedServers: [{"name":"SpamHaus Zen","dns":"zen.spamhaus.org","site":"http://spamhaus.org","txtRecords":["Error: open resolver; https://www.spamhaus.org/returnc/pub/2400:cb00:65:1024::a29e:8507"]}]) Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: 88.64.0.128.zen.spamhaus.org has address 127.255.255.254 Host 88.64.0.128.zen.spamhaus.org not found: 3(NXDOMAIN)

The refreshed Cloudron e-mail setup page shows the following after unbound restart:

This server's IP 128.0.64.88 is blacklisted in the following servers - Composite Blocking List, SpamHaus Zen

BTW: I was the one with the unbound issue (https://forum.cloudron.io/topic/8864/dns-resolving-problem) - could this be connected?

@AartJansen for new apps, AAAA is automatically added. For existing apps, go to Domains -> Sync DNS.

Just came to ask about this, thanks for always being on top of things cloudron team!

@arshsahzad the ocsp thing is only a warning and not a fatal error. But let's continue on support.

@p44 This is a bug in the current release, which is already fixed. To workaround, put the backup somewhere in the filesystem and import using the Filesystem provider.

@hovinen Ah yes! docker returns 404 it seems when it doesn't have enough disk space to store images. I remember this (again) now. Unfortunately, the API has no way of detecting this.

@girish said in DNS resolving problem:

@nichu42 OK, thanks. I am not sure why the forwarding is needed. But if it works...

Alright, then I will keep it that way.

But I have a bonus question: The favorite DNS server I'd like to use (UncensoredDNS, very close to my VPS location and thus extremely quick) is only reachable through DoT or DoH. Do you know if it's possible to make this work?

I've tried to modify the forward-all.conf like this

forward-tls-upstream: yes forward-addr: 91.239.100.100@853#anycast.uncensoreddns.org forward-addr: 1.1.1.1@853#cloudflare-dns.com

but it didn't work (SERVFAIL).

@SignalScout On the server, please try host -t NS example.com 127.0.0.1 . Does that work? Sometimes, it takes a bit for the NS of a new domain to propagate. One just has to wait it out.

@girish
The resolv.conf has nameserver set to 8.8.8.8 and 8.8.4.4.

I did notice that when I ran the script it would overwrite dns and set to 127.0.0.1.

I edited the /etc/resolvconf/resolv.conf.d/head file and permanently added nameserver 8.8.8.8 and 8.8.4.4

Ran the install and successfully installed.

Thank you for your assistance!

This came up a couple of days earlier as well when we were trying to fix @samir 's backup situation. Currently, we lose track of old backups. And since logs and event logs are also gone, it's impossible to know why the cleanup didn't happen 😕 Could even be a remote/cloud storage issue, who knows.

Have to look into how we can make this more auditable.

@TomsFreitas an idea is to then check cloudron server logs.

LDAP logs are suppressed by default. For this:

Edit /etc/systemd/system/box.service Find the Environment= line. Change "DEBUG=box:*,connect-lastmile,-box:ldap" to "DEBUG=box:*,connect-lastmile" systemctl daemon-reload systemctl restart box

Now, maybe something appears in /home/yellowtent/platformdata/logs/box.log .

This can be set to solved !

Cloudflare reply :

c09bd926-0b5e-4850-8e26-b9413779a021-image.png

Sorry to resurrect an old thread. Was recently struggling with migrating (using imapsync) an Office365 account, and it seems to do with Microsoft deprecating Basic Auth method for authentication so there's a whole set of hoops to run through to publish an application in Microsft Azure and get an OAuth access token and what-not to use in the imapsync. It's an over-complicated process.

The workaround I chose since it was thankfully only one mailbox was to setup my local Apple Mail.app with the Exchange account, and waited for everything to download locally. I then used it to export the the mailbox folders which it only does in mbox format. This is where our use-cases align I believe as I was wondering how to import this since Cloudron's mail server uses maildir instead of mbox.

I then learned that Roundcube imports mbox data directly, so simply imported through the app interface and it worked well. Just thought I'd add this as an alternative solution for anyone who comes across this in the future. Turns out Microsoft made the whole imapsync process nearly impossible to use due to their deprecation of Basic Auth just recently in October 2022.

@cleveradmin OK, I reread your original post and understood now. You are offering your setup as a way to understand how to recover MySQL which is in some indeterminate state. In general, we don't attempt to recover databases unless it's super crucial. It's almost always just easy to recover from a backup and we also don't support setups with no backup.

(IMO, MySQL recovery is very complicated and kind of arcane. Fixing one issue leads to another and it can take days really. So, not worth the effort.)

@girish said in is the "always bcc" now is avaiable from Haraka now?:

@skmgo Maybe I misunderstand the question... but if you are using poste.io , how is this related to Cloudron ? This is the Cloudron support forum, we use Haraka but it's an internal implementation detail.

Sorry, you not, it's my problem because I search haraka such question and finally jump to cloudron forum.

sorry for this mistakes, I am going to haraka github to asking it.

@alwynispat actually, https://forum.cloudron.io/topic/8321/forwarding-the-true-client-ip-address/ is the feature request . Let's continue there.