NethServer Version: 8 Module: Nextcloud, Collabora and Onlyoffice
Hello developers of NS 8,
Here is a list of the updates that are offered to me for installation and that I have already installed on a physical and a virtual machine. The result is that Onlyoffice on the physical machine and Collabora on the virtual machine no longer work. I was able to restore the virtual machine thanks to Proxmox Backup. Unfortunately, this is not possible with the physical machine. And a previous attempt to reinstall Onlyoffice was also unsuccessful. @mrmarkuz is informed and is working on a solution for the Onlyoffice app. But I can imagine that he also likes to spend his free time differently.
I pay almost 300 euros a year for two subscriptions and I seriously wonder why updates are released that result in NS 8 no longer working properly in parts. Why can this not checked in advance?
I think I found a workaround @transocean@Tiago . It seems that Collabora and Onlyoffice don’t like internal Nextcloud IPs anymore, even if there are configuration options for both but they didn’t work in my tests.
In my network setup both ports 80 and 443 are forwarded to the NS8. Hairpin NAT may need to be enabled on the firewall for the port forwardings to get connected correctly to Nextcloud instead of the firewall on the NS8…
So I added a DNS entry for my public IP (11.22.33.44 in the example) to the public Nextcloud FQDN on the Rocky host in /etc/hosts:
11.22.33.44 mynextcloud.example.com
Both services need to be restarted to apply the new hosts:
Hi Markus, the upgrade to Podman 5 with Rocky Linux 9.5 introduces some breaking changes. This article describes what’s happening in detail Podman 5.0 breaking changes in detail.
In short, with the new default rootless network implementation (Pasta) of Rocky Linux 9.5, your containers cannot contact the host’s IP address directly because it is already assigned to the container’s network stack.
It is a rare use case in our platform, because containers are usually servers, not clients. However, if a container wants to reach a service running on the local node, like Ldapproxy, our docs suggests:
--network=slirp4netns:allow_host_loopback=true
Then, there are many other alternatives to fix the issue.
As Steph’s pointed out in another MariaDB-related thread, the VPN IP address is a good choice to reach both the local node and other cluster nodes, e.g. “10.5.4.1”
You could run the container with the old implementation --network=slirp4netns. It seems it is available also in new installations (but we must check).
IMO, we should avoid the automatic update of applications with Certification Level 1 and 2, in case custom repositories are enabled in a cluster with an active subscription.
