Cloudron Forum

We're using SendGrid in combination with Cloudron and every time we invite users with a Google/Gmail email address, the invitation is classified as spam email by Google. If you move the email manually to the inbox, Google seems to automatically learn with that action and classifies the next emails delivered by GitLab not as spam.

SendGrid sender authentication is completed, also DKIM, SPF and DMARC are set and validated. Domain reputation pointed out by SendGrid is 100 %.

The Cloudron built in test emails are delivered to the same Google addresses without the spam classification.

Send a test email from the GitLab rails console, it also works. Maybe a problem with the email template GitLab is using?

Tests with some other email providers were successful, only with Google we're running into this behaviour.

Maybe anyone else had a similar problem/can provide a workaround?

@d19dotca Same here. We're currently using it self-hosted, but I would prefer to shift it to Cloudron, because it's less time to maintain and a harmonized concept for all the stuff around.

@ajtatum Would be great to have the app within Cloudron. Right now it's self-managed by ourselves with Portainer.

@girish Nice, thanks for implementing.

@MooCloud_Matt What do you mean without a file sync?

I already tested to edit files in the Web IDE and committing it back to the repository. That works for me. Only the diff comparison is not working on my side.

@girish That's cool, thanks for providing the instructions. It's working.
To confirm, a restart is not needed, I tried it without.

Maybe it would be helpful to add the command to start GitLab rails for feature enabling to the Cloudron GitLab help page.

Before opening the thread, I only pasted the command Feature.enable(:vscode_web_ide) into the terminal and got a bash error.

@girish I already read about that in the GitLab KB, but I don't know how to access the rails console.

Maybe something to wait better until it's out of beta?

GitLab announced in Version 15.7 the new beta feature for the VS Code Web IDE. I tried to test it, but without success.

Maybe someone in the community tried it with success?

Thanks for your feedback. Hopefully after the beta it gets part of the Cloudron family.

Bitwarden announced a new deployment option with low requirements for the hardware:
https://bitwarden.com/de-DE/help/install-and-deploy-unified-beta/

@girish @nebulon Is it planned to integrate that into Cloudron?

Today I set up the docker registry in Cloudron and linked it to the GitLab instance. As we're also using Docker in combination, I tried to add the registry also in Portainer.

It works without any problems, to add it, if you enable TLS and disable the certificate check because they are self-signed as mentioned in the KB article.

To export an image to the registry, you first have to go to images and add the tags with the slug of the repository in GitLab. After that, you're able to export the image.

Doing the same from the Container UI page it failed. Also the browsing the registry via the Portainer UI failed:

Sep 19 09:08:37 time="2022-09-19T07:08:37.105514892Z" level=warning msg="error authorizing context: authorization token required" go.version=go1.16.15 http.request.host="localhost:5000" http.request.id=0f1d08ef-ff99-4921-978e-f332e72c931d http.request.method=GET http.request.referer="https://portainer.example.com/" http.request.remoteaddr=111.112.113.114 http.request.uri="/v2/" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 172.18.0.1 - gitlab.username [19/Sep/2022:07:08:37 +0000] "GET /v2/ HTTP/1.1" 401 87 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 ::1 - - [19/Sep/2022:07:08:37 +0000] "GET /v2/ HTTP/1.0" 401 87 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 time="2022-09-19T07:08:37.16684767Z" level=info msg="authorized request" go.version=go1.16.15 http.request.host="localhost:5000" http.request.id=04bfc005-02d5-44a2-b970-f83bb1105f77 http.request.method=GET http.request.referer="https://portainer.example.com/" http.request.remoteaddr=111.112.113.114 http.request.uri="/v2/" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 time="2022-09-19T07:08:37.166918103Z" level=info msg="response completed" go.version=go1.16.15 http.request.host="localhost:5000" http.request.id=04bfc005-02d5-44a2-b970-f83bb1105f77 http.request.method=GET http.request.referer="https://portainer.example.com/" http.request.remoteaddr=111.112.113.114 http.request.uri="/v2/" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36" http.response.contenttype="application/json; charset=utf-8" http.response.duration=1.673273ms http.response.status=200 http.response.written=2
Sep 19 09:08:37 172.18.0.1 - - [19/Sep/2022:07:08:37 +0000] "GET /v2/ HTTP/1.1" 200 2 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 127.0.0.1 - - [19/Sep/2022:07:08:37 +0000] "GET /v2/ HTTP/1.0" 200 2 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 ::1 - - [19/Sep/2022:07:08:37 +0000] "GET /v2/_catalog HTTP/1.0" 401 145 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 time="2022-09-19T07:08:37.28534889Z" level=warning msg="error authorizing context: authorization token required" go.version=go1.16.15 http.request.host="localhost:5000" http.request.id=d8c321cd-4c9d-4063-b274-c06a30de6a6f http.request.method=GET http.request.referer="https://portainer.example.com/" http.request.remoteaddr=111.112.113.114 http.request.uri="/v2/_catalog" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 172.18.0.1 - gitlab.username [19/Sep/2022:07:08:37 +0000] "GET /v2/_catalog HTTP/1.1" 401 145 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 127.0.0.1 - - [19/Sep/2022:07:08:37 +0000] "GET /v2/_catalog HTTP/1.0" 401 145 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 time="2022-09-19T07:08:37.54718746Z" level=warning msg="error authorizing context: insufficient scope" go.version=go1.16.15 http.request.host="localhost:5000" http.request.id=f1263d9d-17d7-4d84-955b-38bc2779d61e http.request.method=GET http.request.referer="https://portainer.example.com/" http.request.remoteaddr=111.112.113.114 http.request.uri="/v2/_catalog" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
Sep 19 09:08:37 172.18.0.1 - - [19/Sep/2022:07:08:37 +0000] "GET /v2/_catalog HTTP/1.1" 401 145 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Maybe some API endpoints are not supported, like /v2/_catalog?

The Portainer KB points out, that the official Docker Registry API v2 have to be supported.

Perhaps some else also tried it with Portainer or have some ideas why it doesn't work.

Personally, our requirements are very basic. We wish to have some global notification settings for warnings and alters via email. So if we're not checking our Cloudron dashboard frequently, we nevertheless miss important things to handle as admins.

Failed backups or inaccessible backup locations could be part of these notifications via email.

@nebulon Works. Thanks for the fast fix.

@nebulon Is this error opening files in the GitLab editor also the same? I attached a video from our Cloudron GitLab instance.

Recording

@scooke said in Installation on an AWS EC2 server (T2.Micro) at AWS China hangs:

@andreas True, it doesn't matter where the host company, or head office is located. Anything in China, for China, is going to be under lots of scrutiny.

Unfortunately true, we must accept this learning curve.

I suspect the problem is this:

https://stackoverflow.com/questions/29422709/cant-connect-to-ec2-instance-over-http-from-outside-aws

@robi I will try that after I have no more options with the Cloudron support team.

Email is sent. Same result as before.

I think the updates of the packages are the problem that slows all down. I can send the logs after installation if it would help?

I terminated the instance to test the whole thing again from the beginning with the recommended settings. This means that the installation will probably take several hours.

Unfortunately the message has overlapped with the termination. I will give you feedback if everything fits or if I have sent the mail to your support address.

With the additional rule the pinging worked, thanks for the great tips and the incredible fast support.