Hi @schulzstefan @giacomo @alefattorini
As almost anyone here knows, I’m a fervent supporter of virtualization and containers, absolutely.
→ I do accept docker, more out of necessity than approval!
Why this?
Docker, while helping to solve a lot of existing issues, as such has introduced a few - for lack of a better word I’ll call it “mentaltity” issues, that actually worsen a general situation than improving it.
Examples:
Security general:
Programmers take up the attitude: Oh, great, I don’t NEED to worry about security, my app is alone in it’s docker container…
What happens to simple universal tools like rsync has been detailed enough above…
Hardcoded application IPs:
Often, also sadly in the case of NS8, certain “hardcoded” IP, often entire networks are used, without any word of warning to users, that this can present minor or major problems, if your LAN happens to be running on such a network…
Hypothetically wondering what happens if the internal 10.5.4.0/24 IP used in NS8 node for WG-VPNs happens to be the LAN IP of the site installing NS8 as sub-node or primary site?
- IP conflict for default gateway?
- Difficult to find routing errors?
- worse issues?
Worst of all, such programmers do not even bother to place such information eg in the system requirements. For NS8, you need to read a LOT before finding this small detail…
PS: I found the information here:
I couldn’t find much info in the latest Admin Docu for NS8 about the used IP. or internal VPN… 
https://ns8.nethserver.org/en/latest/index.html
→ Hint intended for @alefattorini … 
As to running “a simple linux server” - for me it greatly depends on tasks, requirements, and using the right tool to solve a problem or need.
As an example, I make a big use of SBCs like Raspberry PIs and Odroids for certain tasks - including Home Assistant (I’m a great fan of Home Assistant, too!).
Home Assistant runs basically in the present suggested mode as docker orchestrator, similiar to NS8.
The IP network 172.30.33.0/24 is used internally. In this sense, there is hardly any word of warning about this to users, especially home users and supporters. I personally had to help 3 users using that IP range by pure chance for their home network. This actually caused IP conflicts, as the IP was exposed externally, due to bad firewalling / configuration, etc…
→ This lack of information about docker-internal IPs should NOT happen!
As long as it’s clearly stated, eg in the form of:
This docker application uses IP ranges: 10.x.x.x/24 etc, this could cause issues if this network is locally used eg as LAN…
I do agree that 10.5.4.0/24 is an “obscure” network, but there are plenty users here using a 10.x.x.x network without any real need (like having several sites or over 100’000 IP users in their networks!
Yes, there are people who like to use “obscure” IPs for their networks, either out of security by obscurity mentality or some other reason or need…
This may not be best practices in networking, but it’s all still legit according to the RFCs!
And, yeah, I’ve often stated I’m a networker, not programmer!
and as such, I’m playing the part of devils advocate ( Advocatus Diaboli) - from a network vantage point!
My 2 cents
Andy
But you can do it: no lock-in.
