Cloudron Forum

I could not let go if it, so I kept digging a bit. I had previously reset the memory limit back to its default, but bumped it to 6gb now for another test. This time the restore of Nextcloud went through. So now everything is operational again (and I also cleaned out some apps that had errors, but I was not using anyways anymore). To get back to a working state I needed to restore each up using a postgres database to the state from before the upgrade to 8.3.0. Else the app would have no data in their databases (Mastodon users and toots gone, Matrix rooms gone, for example).

Ah, I just found the error. For whatever reason the 2fa got disabled for my user and therefore the cli app did not ask for it. My password manager always filled out the 2fa field so I was unaware that it had actually been deactivated.

I will leave this question as unsolved.

@visamp said in New Hetzner Server Installation Best Practices: Do you recommend installing CrowdSec or not? Maybe it's overkill? I had it installed once, looked at pretty graphs for maybe 4–5 days. Then I forgot it, re-setup the server and did not install it again. So, I can not even tell you if it was helpful or not. But what I can say is, no one here really uses crowdsec, nor maintains support for it with cloudron. Good thing is, backup or snapshot, try it, decide for yourself, rollback if it is not to your liking.

Ok thanks. that was helpful! For other people seeking answers: You need to setup new subdomains & app to get one user by app. Example: Tony : tony_n8n.app.mydomain.com Chris : chris_n8n.app.mydomain.com etc

@joseph that was indeed correct. I just generated another token, and it is now working correctly. There was an issue with the Gandi dashboard yesterday. Did not take the time to properly troubleshoot it. Looks like it indeed was a problem on the Gandi side of things. Thanks for your help. Side note: I love your product, and I have been happy paying subscriber for the past few years now. Keep up with the good work

@sweetea got your mail in support, will deal with that there.

Just a quick note here. Route53 supports TLSA records now.

@tzolak yes, no worries

@jdaviescoates said in Cloudron seems to have changed to set-up ?all SPF records instead of ~all - why?: whereas only my newer ones have ?all I checked some domains on my Cloudron and noticed one has -all where all others have ~all. Then I realised that one was a recently transferred domain that was already 'working' and obviously the previous hoster had it like this, Cloudron didn't touch it when "importing" it.

The posted error logs do not seem to be related as far as I can tell. But anyways if some food solves it, even better, hopefully also stays that way

Not sure what you mean with "redirect" here, but the code checks if the DNS A (and AAAA if you use ipv6 also) are in sync at all configured nameservers for this domain. So basically you just have to make sure that you have setup A records for my.heavendigital.com.br pointing to your server IP. Then after some time, depending on your DNS provider, this should succeed.

@girish Much appreciated

I never thought of this use-case. Using sftp inside a Cloudron app to move data away. Unique, I must admit. Testing inside a LAMP app to the new unstable SFTPgo app. mkdir -p /tmp/testing; cd /tmp/testing ssh-keygen -t ed25519 -f /tmp/testing/this -q -N "" # put the publickey into my profile in sftpgo.cloudron.dev sftp -i this -P 2022 elias.hackradt@sftpgo.cloudron.dev:/ sftp> put /app/data/tcl.zip [image: 1740783672764-e26df4a0-195d-43cb-9f69-46f3fa8516d4-image-resized.png] Seems to be working Sorry, where was I? Ah yes, your issue The error message OpenSSL version mismatch. Built against 30000020, you have 30100070 indicates that the version of OpenSSL used to build the sftp or related binary (such as ssh, libssh, openssh) is different from the version of OpenSSL currently installed on your system. Specifically: Built against 30000020: This means the binary was compiled against OpenSSL version 3.0.2 (I think don't pinpoint me on the semver). You have 30100070: This means your system currently has OpenSSL version 3.1.7 (same again, don't pinpoint me on the semver, not used to the 30100070 format). This mismatch can cause compatibility issues because the binary expects a specific version of OpenSSL but finds a different one at runtime. Running this in my LAMP App: openssl version OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) and ssh -V OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2 15 Mar 2022 Reveals, there is no issue inside the LAMP app. @chetbaker Could you maybe run openssl version, ssh -V and ldd $(which sftp) in your app with the id 23f10ac0-d9a3-4a1d-8265378464d7b1caasdasdas0 and post that output? Also can you tell us what app 23f10ac0-d9a3-4a1d-8265378464d7b1caasdasdas0 is? Since most apps are inherited from the Cloudron base image, that should be the same everywhere. So this error might be rather unique to your app. Could it be that your app is a custom packaged app? Since you are comfortable using the cloudron-cli, is this by chance an issue from your custom packaged app?

You can also follow this great guide and set up an automated blocklist update: https://forum.cloudron.io/topic/3795/firewall-spamassassin-automatic-list-update/41?_=1740739173375 Might mitigate some (few) of these annoying spam attacks.

Somehow, this issue resolved itself overnight. I mean yea nice, it solved itself, but I wanted to understand whhhyyyyyy. Anyway. #SOLVED

For the future generations: better do ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf to avoid messing with system's and cloudron settings Or use netplan's WireGuard capabilities.

@NCKNE added in https://git.cloudron.io/platform/box/-/commit/f78f6634fa29e0ca638f482c8e4f941c885e6301 . It hasn't run through our CI yet, but maybe that works for you already . You can patch server at /home/yellowtent/box/src/externalldap.js .

Thank you for your answer. So I have to figure out how to redirect port 443. As it stands, I can't, but I'll try to find a way, thank you and good luck!

@im-fabian can you reach out at support@cloudron.io ? I think we have debug further with access to the server. thanks!