Cloudron Forum

Looks like that was the fix, now it doesn't change the A and AAAA records of the email server, and Cloudron can still use my External SMTP connection while having the Mail Server Location set to "cloudron.blockbluemedia.com".

Ahh ok, that makes sense was just looking for clarification if that was the behaviour of that setting.
Will try setting to something arbitrary for the moment and hope that it doesn't change the A and AAAA records, but from your explanation, it shouldn't in theory.

Thanks for the advice @girish

The MX records appear to be unchanged by Cloudron, but the A and AAAA records get changed from my email server to Cloudron, which causes emails to not route correctly as they are trying to be directed to my Cloudron Server, and it needs to go to the Email Server.

I have already made the necessary changes to the SPF and DKIM records to allow Cloudron to send emails out, and that works, but it's just the A and AAAA records that it keeps changing.

Not sure if that "Mail Server Location" option in the screenshot is causing anything of that.

Also for reference, my email server is hosted out of mail.blockbluemedia.com, while the Cloudron server is out of my.blockbluemedia.com (as seen in the screenshots).

It's not too big of an issue, but one that I have to deploy a workflow for monitoring those records and automatically changing them back, if Cloudron changes them.

I seem to be running into an issue where with my cloudron instance is changing the email DNS records I have setup every time I sync the DNS records, when I am using an external mail server and have the DNS records setup to point to that one.

Not sure if there is a setting that I am not seeing, but it seems that the Cloudron is assuming that my email server is Cloudron, when I have an external system that I've configured within Cloudron, and it overrides the DNS settings for that service to put its own.

Might be something that if Cloudron detects an external email service being used for a domain, then it doesn't change the DNS records for that. But if mail is going through Cloudron, then it does change the DNS records to ensure that it's setup correctly.

It seems that the "Mail Server Location" might be triggering that DNS change, but unsure if I set this to something else that it will try and change the DNS records to something else.

Have posted some screenshots of what my settings are set to (with the credential info obscured) and if anyone has any ideas, would love to hear what I can do to change this (for context, my DNS goes through Cloudflare for both my email server and Cloudron).

@girish Thanks for looking into it and I tried again with the Amazon S3 backup option in my server, and it started working for me as well (after you said that you enabled it within your AWS Account.

I think that might have been the main issue as the error message called out that it couldn't object cloudron-testfile (which it might do through the Cloudron AWS Account if it exists*), so if the region wasn't enabled within that account, it wouldn't be able find the correct endpoint to use for that test file and hence wouldn't know where the correct endpoint is.

I say that with the typo that you identified in the backup config code and enabling the AWS Melbourne region within your AWS account, that managed to get it working. In any ways, thanks for looking into this and getting it working for me

@girish No worries at all (sorry for not responding, have been busy at work).

Made that change to the index.js file, however it still comes up with that same error as before.

Curious if because the Melbourne Region isn't on by default for AWS accounts, it might be excluded or hidden by default from whatever API Cloudron is accessing to try and get to the right endpoint.

When using the S3 compatible option in Cloudron and manually typing in the endpoint on the AWS Endpoints doc for S3 Melbourne, it does work so might just be whatever api it's trying to lookup for the endpoint that doesn't have the Melbourne endpoint programmed in yet.

Curiously looking at the index.js, all the other options for Linode, DigitalOcean, etc. have their API endpoints listed there in, might be better to do that with Amazon S3 so that it has a direct link to the S3 endpoint for that region maybe.

Just a thought, but will use the S3 compatible option with the Melbourne S3 endpoint for now as that's working into my S3 bucket into AWS.

@girish, thanks for adding this into the latest version of Cloudron, but unsure if this is an issue with the config or my server.

When I try to use it it comes up with an error regarding "UnknownEndpoint" and it looks like the port and details might not be set correctly for the region, but unsure if this is an issue on my server or not.

I've attached a screenshot of the error (I've blacked out the bucket name) and I've double checked that the firewall rules are set correctly, the s3 bucket and access key settings are correct, and the necessary access point for Melbourne is set within my AWS Account (it's set to internet for the moment).

Hi, as the AWS Melbourne region just went live, have been wanting to migrate my server over to the Melbourne region including the backups to S3. Are you able to add the Melbourne region (ap-southeast-4) into the Amazon S3 list of regions within Backups?

I tried to use the S3 compatible option using the standard endpoint, but it came up with an error regarding invalid url (s3.ap-southeast-4.amazonaws.com).

@nebulon Thanks for completing that

There was a security vulnerability that was discovered within the 7.14.0 version of Confluence Server. According to Atlassian, this has been patched in version 7.14.1 so was wondering if we can get the package updated to ensure that this is patched for anyone with Confluence Server on Cloudron.

Link to Article from Atlassian: https://confluence.atlassian.com/security/multiple-products-security-advisory-unrendered-unicode-bidirectional-override-characters-cve-2021-42574-1086419475.html?subid=1567544280&jobid=105251298&utm_campaign=multiple-products-advisory_november-2021_EML-11738&utm_medium=email&utm_source=alert-email

@girish, was wondering if there is still the possibility of this being packaged into Cloudron as the end of life for Jira Server is 2024 which leaves us with alot of time for this to still be usefull.

Also there for this to compliment Confluence who is already packaged, and looking at the documentation for the install of Jira Server, it seams very similar to Confluence so not sure if this is on the cards yet, but would be good to see if this can be integrated into Cloudron.

Looking at the confluence versions recently, it would be great that the package of Confluence can follow the latest LTS release of Confluence Server, which would be 7.13.1 (to make sure that it also isn’t affected by the Confluence Security Advisory published by Atlassian).

Also to make sure that the package is updated for any recent marketplace apps published in Confluence Server.

@nebulon Thanks for clarifying that and will re-enable the automatic updates. Was just checking to see if there was a seperate channel for those and why I constantly saw the message saying that it was pre-release and not considered stable.

I’ll stick to the automatic updates as that follows the schedule of controlled updates from Cloudron, and I completely understand that some people would be willing to get the latest paches and releases for dev environments (for example).

Although maybe expanding the update options to include weeks and months might be good as some people/companies might prefer an patch management and update schedule each month rather than each week (just an idea but happy for your team to focus on more important features and bugs).

Whenever I try and update my system, it’s always coming up with beta updates and I can’t opt-out of the beta updates and only get stable ones.

Was wondering if there can be an option to only get stable release updates and have an opt-in option for beta updates of both the platform and apps.

I would love to have those stable updates happen automatically but it seams that whenever it would update, it would always be the beta updates that are unstable for some reason.

Happy to discuss but was wondering if there was an option to include here for only allowing the updater to access stable updates for both apps and platform updates.

As Confluence is already within Cloudron, having Jira within there would be great for linking the environments together and using them together.

Have been looking for an easier way to have a Confluence and Jira Server together and if Jira was integrated into Cloudron, it would accomplish something that I've been trying to accomplish for quite some time.

I believe there is already a Docker version of Jira as well that could be used for this: https://github.com/teamatldocker/jira