One of the wifi networks (I do not have control over) uses bogon IP space for addressing. When connected to this network I cannot access any Cloudron servers. Do they block bogon? If so, how can I white list a network - in specific 100.64.0.0/10?
@girish & @mehdi - thanks for your advice! It gave me the idea to Tailscale. I installed it on the Cloudron server and was able to successfully mount a shared folder from my Synology using cifs. However, even though the data persists between reboots, I don't see the data on the Synology, even when I'm logged in as the root user. I'm not quite the linux expert, but I noticed that when I changed Nextcloud's appdata folder to point to the mount, it created it as a "root" user. On the Synology, I created a Cloudron user that has the necessary permissions and I mounted the shared folder with the Cloudron user, password, and domain. So, I'm thinking this has something to do with user IDs not matching up or something like that.
I'm nervous about moving forward since I can't actually see the data on my Synology. Would you or anyone else have any advice?
By the way, this is how I mounted it:
sudo mount -t cifs -o credentials=/etc/nas-credentials,vers=3.0 //nas/Cloudron /mnt/nas
In fstab, the command is:
//nas/Cloudron cifs -o credentials=/etc/nas-credentials,vers=3.0,_netdev,auto 0 0
no, only 2-3 ports tcp/udp (wireguard/snmp/ssh)
and it happened inbetween again, without any reboots/upgrades/etc. I got notfied by network mgmgt system, that my cloudron server is down - luckily it was just the firewall…
@cumpal Cloudron expects to be the only one running on the server, so for security reasons it locks it down unless needed by Cloudron or any of the apps on it. If you need to modify it, I think you can just update the firewall rules manually in Ubuntu, though I've not done that part myself as no need for it yet. but hopefully that at least explains why it's locked down. You may want to review the Cloudron docs on security features too.
@jdaviescoates Correct, if you use Gandi API you are using wildcard certs and good.
When a cert is issued, most of the current certificate providers these days "log" the domain name as part of the https://en.wikipedia.org/wiki/Certificate_Transparency project. These reports can then be scanned later. For example, go to https://crt.sh/ and search for say %google.com%. This gives various subdomains of google. When you use wildcard certs, only *.domain.com is logged and thus the subdomain is hidden. So, if you install searx at mysecretsearch.domain.com, there is no way for anyone to know the subdomain mysecretsearch since DNS has no subdomain search.
Follow up from the customer: "The issue here turned out to be that in Wordpress, WP Rocket caching plugin was used. This plugin automatically starts to preload the cache of each page once something in the site has been updated. The preload itself causes some stress on the CPU and maybe some other processes. Turning off the plugin, the products were sent for less than 2 mins."
They are working with the WP Rocket team to find a workaround.
What ports do you think I should be concernet about forwarding packages? Is it just 80, 443 and 25? I've taken a look at cloudron_firewall.sh and there's a bit more stuff going on there, isn't there? Heheh