Which means you’ll have to create mounts/binds for every directory you wish to sync? (Assuming the app doesn’t get filesystem access by default, which the native service on Core obviously does.)
Well, you could just bind /mnt
I’m confused, why would rsyncd want/need “filesystem” access? What’s wrong with mounts?
Common language: on a server/NAS your typically “pulling” (from your laptop) and (assumption) you’d have datasets for the server/NAS to pull to.
Agreed. Same with NFS (which is insecure by default). I think an upcoming version of SCALE is also going offer NFS as an “app” to harden the NAS’s security. Just mount as needed for directories you wish to access via NFS.
No. There are no plans to make the NFS server an app, and I don’t understand the justification for doing such.
1 Like
I believe the point was: removing a “built-in”. Like if someone were to try and remove Vi from base. -i.e. Even though rsync isn’t really a ‘built-in’ it is relied on by many as it were.
The absolute basic form of rsync is rsync <from> <to> (pulling on the ‘local thread’) but that functionality is already baked in with cp, tar etc. (I’d go with tar just for the file exclusions, and preservation of acls, xattrs, and whatnot but that could just be my ignorance).
[strikethrough]
Having rsync as a ‘separate app’ would allow for policy-based routing so I think the tradeoff of having to make a few mount points is little.
[/strikethrough]
There is something to say about security, but I’ll leave that up to far smarter people than I to discuss.
EDIT: I replied to your post Winnielinnie so you can fix my mistakes in the interpretation.
EDIT2: I just saw a thread about how separate IPs is not possible so, striking that comment (sorry). *sigh*
I was being tongue-in-cheek.
They cited security reasons for the removal of the Rsync Service in SCALE. Then later, it’s offered as an app, which makes it more secure.
Yet NFS gets a free pass? By default it has unhindered access to the entire filesystem. (No need to mount/bind anything in order to create an NFS share). By default it has no authentication nor encryption. (Anyone on the local network can mount the NFS share without the need to authenticate with a username/password.) The best security offered, without the convoluted Kerberos, is to employ an “Allow List” of permitted hosts or IP addresses. Guess what? The Rsync Service also has that safeguard.
So I have still yet to understand how the Rsync Service was deemed too insecure and must be relegated to an app with mountpoints/binds, yet NFS is fine to leave as a built-in service?
(Not to mention that the Rsync Service is apparently not too insecure for enterprise customers on Core 13.0-U6.2. Only for SCALE is it a security issue.)
So, I’ll attempt to not sound like a complete idiot, but I cannot promise anything because this is not my area (this is above my paygrade).
“Individual software security policies” are the issue and is what I think they are talking about. Think: OpenBSD and ‘pledge’.
Reference/example: capsicum(4) (freebsd.org)
Google ported that to Linux but I don’t know more than that.
This isn’t being made because of the GPL.
OpenRsync
GitHub - kristapsdz/openrsync: BSD-licensed implementation of rsync
It’s also part of the kernel.
Only way is to use CLI and call rsync that way. I’ve opened a Feature Request here Rsync Task should allow local 2 local synchronisation ( Local Destination Target ) - Feature Requests - TrueNAS Community Forums
I periodically use external drives via USB to backup files. I don’t always need to replicate a dataset, so it would be handy to be able to set an rsync task up in the GUI instead of running a fancy script I have now.
Easy peasy on
- Debian
- Ubuntu
- FreeBSD
- Mac OS
All of these can import a current TrueNAS ZFS pool. No need for a server.