I would ask instead
how adding an “rsync ecception” can worse the comprehensive security of the comunication between two containers?
how much the security of the recipient containers can be compromised via rsync?
Currently any connection among orchestrator and container has been designed in a specific way. Also the interconnection between containers for login.
rsync is a whole another beast to design from…
it was a hypothetical,
Anway, ill focus on designing tools within the given constrains of what is permissible within the Nethserver 8 Universe, and ill minimize my insistent quests for having things implemented In a given way, as for conformity of some given norm standard of other design systems.
IF other tools are not doing it, Don’t do it.
IF the dev team says its not to be done, Do not attempt a way to achieve it.
this is what developers do all the time, turn around an issue to fix it
in code we trust, and so, nothing is impossible
Allow me to quote this article
other are better than me
Unlocking the Power of Podman: Advanced Container Insights | Medium
Also, form the dev docs here
Rootless vs Rootfull | NS8 dev manual (nethserver.github.io)
Question, is it possible to have a limited rootfull module?
Technically, making use of rootfull modules, it should be possible to implement 2 separate modules, talking to each other, sharing the same Mounted volume file folder location
Ready to compromise security for lazyness in programming?
You sound really desperate!
Just because anyone can jump out of a window from a tall building, I still do not think it’s worth the ultimate selfie to try doing it.
But it’s possible!
Another option is opening up for script kiddies, let them take over. You will have both communicating. Maybe not what you want, but hey, it’s wonderful. The modules are finally communicating!
My 2 cents
Andy
Equally, there are already rootfull Apps in ns8.
I am trying to understand what spossible, and whats within scope, thats why the questions.
if you can do it rootless, do it rootless
if rootfull is needed, it is mainly because you have to access root host ressources. One example zabbix cannot use as is fping, but you can turn around the issue
rootfull means root, no way to have half root or maybe a user linux that you can elevate the privilege with sudo
I am still on this topic, and still researching on possible solutions.
Seems i am not the only one who encountered this problem.
reading this article, someone created a script to transfer files between containers here: Transferring data across docker or podman volumes - DEV Community
someone else seem to have created rsync docker here: GitHub - ogivuk/rsync-docker: Rsync as a Docker container based on Alpine
Given enough resource,s i could probably try to get things working, but i still feel at the core level, Ns8 should implement these functionalities.
the ability for 2 separate apps to share volume data and or files.
I know you might be talking about security but,
it would have to be enabled between the 2 containers first.
all the app as running as rootless
the communications are private within the given Node or cluster.
Plus, when the core dev team implements the functions, they would be mor keen on security practices since they understand Nethserver 8 better than i do, than if i attempt to implement such a function
it would probably work kind of similar to how apps detect each other and share components, so in this case, there would be room to choose another app to share, and map volumes required.
@davidep could you please consider this as a core function. otherwise ns8 would be severely limited in integration between containers and data sharing scope
No Martin, as Steph wrote a volume cannot be shared between different Unix users (apps).
This doesn’t mean that two apps cannot share data with some mechanism, like rsync or other protocols. For instance rsync is already used for ns7 migration or app cloning.
That’s basically what I am saying, and even referenced some works that implements a script which uses rsync to handle file copy between containers.
I relation to this, couldn’t we have such a feature implement in the core, thereby as a developer I only need to call the function instead of implementing a full script cycle for every app I need to implement volume sharing?
So the data will be twice on the system…a container will write on one and the other could modify the data and write back on the first
Where is the true data, who is true,who is false ?
This is called the splitted mind when you have a cluster on proxmox and the data differs between the two nodes…in fact you will need a third containers to say this is the true data because I share the same with that container
Well I can be wrong but it cannot work as is.
Why to not use the two containers in the same pod. In that case and in only in that case you can share a data among the same volume
The mail module work like this postfix stores the message that dovecot will serve to the clients. The two container can share the same volume
for some cases, it makes alot of sense to actually to that. however there are numerouse cases it does not make sense to do this.
I cant build an App with 15 different exposed services because i want them to share volumes, it makes no sense.
i can however build each of them independently, and the user decides the ones they want to install and leave out the ones they don’t want to install. atleast with the options to share the data between the same even though installed separately.
Some of the case, if no most are actually read only, and considering multiple different directories are mapped each performs
say i have a tool to download movies, that stores it in a given volume folder, and i have a different toll that is used to watch the said movies, the second one only needs to access the data from the first. and so on…
ofcourse thereare cases this might not be feasible, however there are multiple cases it is
Yes I understand but in that case I would use a jdownloader that will download a movie to a shared folder (samba, webdav, ftp, not really verified all the possibilities it is for example) and I will have a plesk that will share throught http to my smart tv. No need to share a volume and it can be two different containers
my context here on the movie side of things, is in relation to homelab setups, and thus in relation to the ARR stack as well as Emby and jellyfin whatso…
I wanna take some bit of competition to Umbrel and CasaOS
Mostly if app work together they have a channel to share data and communicate. My grand father used to have one server to do one task (it is not true) yesterday we used virtualization and a vm cannot access the data of another vm…and now we have container and we cannot still access the data of another container if they do not have a channel to share data
Now you have to explain your study case and after that I could say you are true and I will maybe change my mind or I could say you could do that to fix your issue
I could also say no idea 
In fact the network under TLS is your only safe way to share data between container
Challenge Accepted.
just to scope abit.
Say i want a Sonarr App Sonarr - Dive in
Which plays well with radarr Radarr
and i need my subtitles downloaded by Bazarr Bazarr
and i am using JElyyfin to watch my movies The Free Software Media System | Jellyfin
Someone else might prefer Emby to Jellyfin
it makes no sense to build a single App that adds all of these apps in one pod. it should be possible for the end user to install what they want to use, someone may have no need for subtitiles, and thus bazarr not required.
One may be using Plesk instead of Jellyfin and thus, jellyfin not required etc.
I could be using NZBGET do download NZBGet - Usenet downloader and someone else uses jdownloader as you put out.
I could be a music fan who uses Lidarr Lidarr
in all these cases, there are some aspects and components of these apps having the need to share Data in one way or another.
I recently added Homarr as a homepage, which integrates really well with all these tools, if they talk to each other, and on the dashboard i can see what movie is being watched, what new episodes are available etc.