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.

@DeBossNow it would really help if you could give more context on what you refer to when pasting plain text from presumably the Cloudron dashboard.

If this is somewhere from the app configure UI, is the app in error state or which state is it in? Is the repair button enabled for that app and if so, have you tried to click that?

@girish I recall you making that run automatically..

Should it run more frequently?

Thanks for the hint, I have added all the supported ones to that list now https://docs.cloudron.io/installation/

@ccfu @warg TIL that OpenVZ stands for Open Virtuozzo ! From https://en.wikipedia.org/wiki/OpenVZ . Added to our docs page then.

I had a similar problem recently. Here's what I had to do in order to be able to programmatically update DNS records for a domain in Google Cloud DNS:

verify domain ownership: https://cloud.google.com/endpoints/docs/openapi/verify-domain-name. I did this by inputting a special DNS TXT record into DNS for the domain.

in my case, I was using a Google Cloud Service Account with Terraform (not Cloudron) to modify DNS records in Google Cloud DNS, so in additional to verifying domain ownership, I had to actually add the Service Account I created as a verified owner of the domain as well.

After doing these two things, I was able to programmatically update DNS records for the domain using the Service Account.

So, assuming you've created a Service Account at Google, given it the "DNS Administrator" role, and added the Service Account email as a verified owner of the domain, you should be good to go. I just tested it with my Cloudron and it all worked. I'm attaching a screenshot of the Google domain verification screen showing where I added the Service Account as a domain owner. Hope this helps.CleanShot 2023-04-26 at 07.28.52.jpeg

@m3pilot not sure what's happening here, something seems totally wrong (like some mismatched node version). Are you able to contact us on support@cloudron.io to debug this further?

@tonimad said in Cloudron and different webmail:

Dedicated server with large calacity of space. Here, on this server, I have my Afterlogic Pro webmail installed.

One simple question, why would AfterLogic be necessary to run, since you want to migrate to Cloudron and run the email service on it?

Cloudron is ready to run all email services out of the box, and that includes webmail as well without any further configuration necessary other than installing the snapmail web app from the repository.

@girish you hit the nail on the head. that was 100% what was going on but odd that it only started doing it recently. honestly, if I could use anybody else but Cloudflare, I would. #takingsuggestions

@warg

Haraka is not as widely used as Postfix but it is also hardly a niche product and has been around since 2011. If anything it is down to preference. Cloudron chose it because it is lightweight and efficient and presumably because it best fit their architecture. The IMAP server in Cloudron is Dovecot, which is also used in Plesk.
What are your concerns?

Yes, the best thing to do is just give it a go and see if it fits your needs.

@BrutalBirdie Even then, we are talking about Android 4.0 and Windows Vista ... Then again, I have heard stories of people using Windows XP still...

@roofboard that makes sense. I would personally not throw in a ssh key into a CI/build system either 🙂

I guess you are looking for a cloudron sync or something from the CLI tool. I guess this is possible to implement. Can you open a feature request at https://forum.cloudron.io/category/97/feature-requests ?

@userino yeah, it's that way because IMAP/SMTP have no concept of sessions. This means that you might have to repeatedly enter 2FA token which would in turn make using mails clients quite unusable.

I recommend generating an app password for Email (what I use personally) and using that as a "throwaway" password. It will work only for Email an won't let you login to other apps.