@ei8fdb said in Cannot load certificate key .../_.sub.domain.org.key failed - No such file or directory:

_.sub.domain.org.key

One of the nginx config files is referencing this key. You can delete the config file and the key/cert file. You can find out which file is referencing it by grep'ing inside /etc/nginx/applications . Once deleted, you can systemctl restart nginx

@girish this was more for Nginx not starting, including 0 byte files.

Happy to mod the FR to be more inclusive. Done.

@mehdi

Yah... Maybe it would be enough just to give the administrator a few controls.

the cron interval the warning level the kill level (kill all modules)

Thanks for the info, but we do not use this module, so we are all good.

@robi this is set for app but not for the dashboard itself which OP was trying to fix. I think we have to add it to dashboard's nginx config when we look into supporting reverse proxy setups properly.

@robi Yes, sorry, I just followed the tutorial that was previously posted by @scooke

https://cloak.ist/blog/how-to-put-a-ghost-blog-at-a-subdirectory-using-cloudflare-workers/

I restarted the application and it works correctly now ...
thanks @girish

@ashkaptsov So, AppGyver's browser UI is going to make requests from the browser to n8n and baserow ? Can you tell us a bit more as to why would it want to do that? In general, adding CORS headers without knowing the app knowing about is a security hole.

I did a clean installation and restored a backup.
Since than, everything is working fine.
Thanks

@mastadamus thanks so much for investigating. I have removed it for next release (7.1) - https://git.cloudron.io/cloudron/box/-/commit/6492c9b71f80120413ff4ae7eefa2f03dc96ea0f

@mastadamus Can you add that as a feature request and mention this thread?

Yeah, I found this exact same spam text in another forum.

it's solved, it was a problem with resolv.conf. The DNS servers of my scaleway instance are not responding anymore ... 😞

I am currently debugging that instance, but just for others to read up, using nginx -s reload as root usually reveals the syntax errors in config files right away, like it was in this instance as well.

nginx configs became corrupt. Once we got nginx up, it uninstalled. I am putting notes on why nginx configs were corrupt at https://forum.cloudron.io/topic/5457/site-is-not-reachable

@nebulon You try to make things easy for us but we'll screw it up somehow. ; )

@mehdi
This my friend is a good point, thank you for pulling me out of the tunnel. lol

@nebulon there was no error reported by cloudron. The issue was that if I tried to curl, there was nothing returned back (I don't remember the exact reply -- sorry for that). Basically it was like nginx was not routing properly, as if nothing was running at the subdomain.

I patch the my.domainname.fr.conf with the missing part (taken from my other Cloudron server).
I then uninstalled and re-installed jingo, and everything seems to work fine now.

Sorry @marcusquinn dident see that you was using ghost for your blog.
in that case, SP_mod will be really a bad choose because front-end and back-end are separate similar on how angular/react works.
I really advice you do optimize your image manually for now, and w8 ghost will release some improvement on that.

Truly heroic support! 🙌 Happy to know this is covered and tested 🙂

@girish I think all these % numbers are a bit misleading and opinionated - but as you rightly detail it's a case of looking at the appropriateness of each item and reasonability.

It's impossible to know or remember everything but still a nice too for a quick review to see if there's any easy wins, and I suppose the scoring mechanism could be handy marketing for some once a certain level is considered reasonably hardened.

Changed 🙂 As it is the default configuration for Roundcube it is working like intended and we could leave it like this? I don't think its a rare use case but maybe it could be added to the documentation (which I always found very helpful).

@girish Went ahead and tried it and it works beautifully! Took a matter of seconds for it to load all my feeds. Really appreciate y'all's work on this. I'm becoming a bigger Cloudron fan by the minute 🙂

@ahkg the reason for whitelisting 172.18.0.1 give access to all requests, is that this is the ip of the Cloudron internal gateway into the subnet where all apps are running.

Unfortunately for your case the cloudron healtcheck also comes via this gateway. I think your htaccess file needs to check for the X-Forwarded-For header to check against the correct inbound address.

Oh I pasted the wrong link apparently, fixed it now.