Cloudron Forum

@djxx ha ha, sorry I misunderstood 🙂

The bounce message is sent from Cloudron for undeliverable messages. You can send randomaddress@domain.com and you will get that bounce back message.

Going back to your original problem, if gmail is blocking you , the only way to unblock is to wait it out. From your original mail, you are getting blocked at IP level. This means that gmail most likely blocked your entire VPS provider range. You have to set up a relay to get out of this situation - https://docs.cloudron.io/email/#relay-outbound-mails . If your mail is only getting to spam (instead of IP blocked), then usually you have to just "wait" it out. From many years ago, we just sent email from cloudron.io to various gmail friends and asked the to mark as not-spam. After that, it started going through. But gmail is a black box, who knows what they do now.

Such posts are totally fine . Even if you migrate the other way around. I think all posts around Cloudron and selfhosting are welcome as long as discussion/posts are civil.

I couldn't find a good way to do it just with GitLab so I went ahead and installed another app. I'd still like to hear if this is possible with GitLab alone.

Overall, it took about 10 minutes to set it up this way, which is better than not having repository functionality. One note is that the way the docker registry app identifies itself, the port is VERY important in how you login. Previously I was able to auth with my GitLab hosted docker repository with a URL like:
docker login registry.mydomain.com

but this didn't work at all with the Cloudron Docker Registry hosted at the same domain. I had to change to:
docker login registry.mydomain.com:443

yes - the port is apparently important!

@djxx oh wow, thanks for the detailed write up! Hopefully it's useful for other people migrating as well. I will add a link to your report from our docs.

@nebulon Yes - I was getting confused about the WebDAV API keys, what user name as needed, etc. The thing that helped the most was clicking on the SFTP dialog for the app, which makes it very clear what the login information is. Clicking on SFTP for the Surfer app shows:
f04ce061-ff35-4938-8219-ff57e38b8783-image.png

Thanks for your help! One more app configured and migrated 😄

Right as I typed that, I realized that there is the "send" icon next to it, which when clicking shows the link to set up the user's account. I realized that I could confirm the user's account on my own. I can initialize the account with the password I want, and then I also see the key icon you're referring to and am able to reset it that way.

Thank you for your help!

@joseph Thanks for this! I was trying to wrap it up last night so I decided to just reset all the users passwords to a known password, and then send them a password reset link to change it to their old password on their own. I will definitely keep the group approach in mind next time I'm migrating to Cloudron - but my next server likely won't migrate until XMPP gets some love 😉 ( https://forum.cloudron.io/topic/10465/xmpp-server-prosody/26?_=1723504540984 )

@girish - Given that the only blocker (that I know of so far) is the TLD certificate availability, would it be a decent workaround to package this entire thing as an application, and then run a one-time command to symlink the TLD certificate into the application directory? This would allow the sys admin to choose which application deserves access to the TLD certificate, ensure the app always has access to the latest certificate, and work around the current limitation of apps not being able to request the TLD cert.

@djxx I wouldn't say running a CI runner a "little thing" 🙂 But anyway, it's up to you if you feel comfortable and are aware of the repercussions of installing things give access to all your containers.

I have no idea about sysbox, never tried it.

@djxx https://github.com/processone/ejabberd/discussions/4095#discussioncomment-7251934