Thanks for the article. I got my Nextcloud office podman setup working fine. This doc clarified how to set it up. I wonder how the CODE server safety is. It’s open to world with no auth?
My setup, which I would assume typical, is that the services are behind HAproxy, and I terminate SSL there. Containers then run behind it, in my case on the same host. I’d like to see the connections between nextcloud and CODE would happen directly within the host, instead of going via public url in external HAproxy. Is there a way to define two addresses for the services, the public one and the internal one? I’ll likey end up running the containers in the same pod, so no need to reach further.
Another question, what does one put here?
It asks for IP address. Now there are many IP addresses to consider, I wish it was more precise. The container internal network IP, container host IP, HAproxy public IP which answers to office.mydomain or cloud.mydomain? If I have X-Forwarder-For URL added to HAproxy, that would carry the original requestor IP, which likely would be the container host for CODE. But then again, will nextcloud read the forwarded for url, or just the HAproxy ip?
I didn’t put anything there yet, and that makes me feel unsafe.
“public URL” is required by the WOPI protocol but definitely you can point public URL to local IP (search term “split-brain DNS” or “split-horizon DNS”)… but you still need to traverse the reverse proxy because of TLS certificates.
this is the IP address of Nextcloud accessing the CODE (how CODE receives this… depending on your config this might be reverse proxy ip or your public IP or your internal IP - look at CODE logs…)
Thanks, I didn’t quite understand what this dot escaped means, but it might give a chance to use the internal nextcloud url as the second allowed source. That would be http, as it would not go through haproxy, but from container to container directly instead. And as it’s http, no need for cert trouble, nor double dns. But I don’t know, guidance is rather short:
aliasgroup1=https://<domain1>:443,https://<your-dot-escaped-aliasname1>|<your-dot-escaped-aliasname2>:443, aliasgroup1, aliasgroup2… and so on should be added as per the requirement. <domain1> is the WOPI host, i.e. your preferred File Sync and Share solution that implements the WOPI protocol, for example share.example.com. <your-dot-escaped-aliasname1>|<your-dot-escaped-aliasname2> are the aliasnames with which you can access the same WOPI host (in this case <domain1>) aliasnames can use regular expressions.If you don’t have any aliases, then only domain needs to be defined, for example aliasgroup2=https://<domain2>:443.
this does not work. all addresses used to interact between the systems must be the same as the client uses. You route the traffic internally (using internal IPs) but there is no way to use internal DNS names…
