Cloudron Forum

CPU is back down to 5% for the last day with just a couple of Ghost websites running. Restarting mail, mongodb and slowly turning on each of the apps. Crossing my fingers that this works.

@bmann said in Github Actions documentation/example for Surfer:

/website/*

This is a bit weird. In the output above it complains that it cannot find /website/, while in your yaml you are passing website/. The first one would be no surprise if it does not work, the second one however should work as ci tools usually open a shell where you will be directly in your git checkout.

I would try to debug this with inserting a few ls and pwd into your yaml to see where you actually are and if this might be a permission issue of some kind.

@rmdes said in Custom Cloudron image for ElasticSearch:

I'd certainly contribute with funding, even more if the app can then be used by other cloudron apps (if possible)

Nextcloud being such a candidate

@bmann said in Standard package formats:

Effectively: what is the difference between some-form-of-buildpacks and Cloudron's current packaging format?

Good question. You should find the information you need in https://docs.cloudron.io/packaging/manifest/

@LoudLemur _DNSLink is a feature of the IPFS protocol that you map a TXT record of the hash of the root of your published website or app and then CNAME at a single IPFS gateway. This means you don’t need to run a gateway for each domain.

Setting up the sieve rule means I have to have the password and set all of that up.

Using the "mailing list" settings means I don't have to do any of that, don't need to create an inbox, and it doesn't need to be owned by any accounts (and cloudron users with email admin / admin / superadmin can modify as needed).

Screen Shot 2023-12-15 at 5.08.26 PM.png

So I guess I answered my own question 🙂 I'll write it up. for people who ask in the future. "How do I set up email forwarding to external accounts without having to provision Cloudron accounts" == mailing list.

@luckow thanks for the SoGo -- looks like that does take care of everything.

Yeah, the access key is what is going to check if the domain is there. I think "Skip nameserver validation for custom Route53 NS names" would get me there 🙂

And all of the DNS and Email stuff...I totally understand how difficult it is to give less technical users the ability to even USE this stuff, as well as support slightly more advanced users. You're doing a great job!

@bmann This helped me after updating to 8.0 which broke IPv6 for some reason 🙂 (I'm also on OVHcloud)

@girish said in Accessing email mailbox owned by a group:

Let's say a username has 3 mailboxes - admin@, support@ and username@ . Which mailbox is seen when logged in? You might say username@ but what if username@ is not in that list?

@girish I think we keep misunderstanding each other here. I know how it used to be back in the day and I also know that for ages now Cloudron has been using the full email address as username to log into emails exactly because of the confusion you've just pointed at with the above example. So I'm with you here.

What I'm pointing out is that if using the email prefix as username to login (and NOT the Cloudron username) then we get around the confusion in your example. So if a user is the owner of three mailboxes - admin@, support@ and username@, then to log in each other them the username would simply be "admin", "support" and "username" respectively, and the password is the user password. I'm not taking about showing multiple mailboxes at once or anything like that. With a single domain this works, there is no confusion and yet we don't need to write the full email address every time but only the prefix which is easy. And this is what seems to be happening in Roundcube right now.

Now this gets confusing with multiple domains becasue a single user can be the owner of say admin@domain1.coop and admin@domain2.coop. But for this "I humbly think" the default behaviour I described in my previous message intuitively solves this issue, that is:

if a user enters only the prefix then the @domain defaults to the domain the webmail app is installed on. So say if Snappymail is installed at webmail.domain1.coop and I enter "admin" as a username to login, then it default to the mailbox admin@domain1.coop. if a user enters the full email address as the username to login then he/she/they can access that mailbox no matter what the domain of webmail app is.

Here is what I wrote in my previous message:

I think it would make most sense and be the least confusing if the username to login is the prefix of the email address, and that it default to the domain of the email app rather than the global email domain. I think that way would be a very neat approach, yet still giving the flexibility to login on any email app installed on the Cloudron using the full email address for niche use cases.

Yes I have DKIM setup. Thanks for the “relaxed” incantation. I’ll try that.

Thanks @nebulon for the prompt fix!

@bmann said in WordPress Migrate Feedback, SMTP Mailer Instructions:

This is a restriction in the All-in-One WP plugin

Like @scooke says, if we're talking about the same plugin, it isn't. As I said, I recently did one over 1GB.