Set up rsyncd for various principal pull targets

oysteikt commented

2026-01-22 05:15:40 +01:00

Owner

Backups might go quicker if we already have a live rsyncd indexing files for incoming rsync connections. We can probably set up seperate instances for every expected pull target used by principal.

👎 1 🤷 1

oysteikt added the nixos services backup labels 2026-01-22 05:15:40 +01:00

oysteikt added this to the Kanban project 2026-01-22 05:15:40 +01:00

oysteikt moved this to Low priority in Kanban on 2026-01-22 05:16:17 +01:00

danio added the disputed label 2026-01-22 08:02:27 +01:00

felixalb commented

2026-01-22 12:51:03 +01:00

Owner

Is the current speed/duration of backups problematic?

oysteikt commented

2026-01-22 13:41:09 +01:00

Author

Owner

No

danio commented

2026-01-29 14:01:23 +01:00

Owner

rsyncd is insecure, it operates entirely in plain text. The only reason it's okay to use rsyncd-started-over-ssh-via-rsync is because the communication is wrapped in the ssh connection.

Even if it was secure, I don't think it's worth giving up the auth-stack of ssh and having yet another always on daemon to think about people connecting to

rsyncd is insecure, it operates entirely in plain text. The only reason it's okay to use rsyncd-started-over-ssh-via-rsync is because the communication is wrapped in the ssh connection. Even if it was secure, I don't think it's worth giving up the auth-stack of ssh and having yet another always on daemon to think about people connecting to

oysteikt commented

2026-01-29 14:18:29 +01:00

Author

Owner

I'm not saying we should throw out ssh, I'm asking to have a live rsyncd instance on the other side of an ssh connection.

It would also give us more serverside control of copy options. You get to declare excludes and whatnot serverside, rather than having the principal script maintain a list of things it wants and things it does not, possibly using nix language and nixos config to generate such lists.

Rather than considering the change a move away from ssh, I'm trying to suggest a move away from rrsync.

I'm not saying we should throw out ssh, I'm asking to have a live rsyncd instance on the other side of an ssh connection. It would also give us more serverside control of copy options. You get to declare excludes and whatnot serverside, rather than having the principal script maintain a list of things it wants and things it does not, possibly using nix language and nixos config to generate such lists. Rather than considering the change a move away from ssh, I'm trying to suggest a move away from `rrsync`.

danio commented

2026-01-29 14:27:20 +01:00

Owner

In that case we might have two very different pictures of how rsync and rsyncd operates?

Are you proposing:

rsyncd on 127.0.0.1:876 or whatever
for everywhere we call rsync now we instead

ssh -R 876:127.0.0.1:876 <machine> &&
rsync rsync://127.0.0.1:876
kill %%

Maybe there's some functionality I don't know about in rsyncd

In that case we might have two very different pictures of how rsync and rsyncd operates? Are you proposing: 1. rsyncd on 127.0.0.1:876 or whatever 2. for everywhere we call rsync now we instead * `ssh -R 876:127.0.0.1:876 <machine> &&` * `rsync rsync://127.0.0.1:876` * `kill %%` Maybe there's some functionality I don't know about in `rsyncd`

felixalb commented

2026-01-29 14:32:38 +01:00

Owner

https://gist.github.com/trendels/6582e95012f6c7fc6542

rsync -av --rsh=ssh remote_host::home destination/

seems to be possible,

https://linux.die.net/man/1/rsync has the section "Using Rsync-daemon Features Via a Remote-shell Connection"

https://gist.github.com/trendels/6582e95012f6c7fc6542 > rsync -av --rsh=ssh remote_host::home destination/ seems to be possible, https://linux.die.net/man/1/rsync has the section "Using Rsync-daemon Features Via a Remote-shell Connection"

❤️ 1

oysteikt commented

2026-01-29 14:35:24 +01:00

Author

Owner

Not sure about the exact setup details, but I imagined just using ssh as the transport layer for rsync. Either force the rsync command with authorizedKeys, or turn off shell access and proxyforward a socket to rsyncd. And then rsyncd would take care of all sandboxing and whatnot serverside.

I also initially thought that a live rsyncd session kept some kind of live list of file hashes or did some tracking of some sort, but I can't find it at the moment. I'm pretty sure I read something about it in the past, but I might have confused things or misremember. That was the reason behind the might go quicker comment up top, maybe that is where the confusion is stemming from?

Not sure about the exact setup details, but I imagined just using ssh as the transport layer for rsync. Either force the rsync command with authorizedKeys, or turn off shell access and proxyforward a socket to rsyncd. And then rsyncd would take care of all sandboxing and whatnot serverside. I also initially thought that a live rsyncd session kept some kind of live list of file hashes or did some tracking of some sort, but I can't find it at the moment. I'm pretty sure I read something about it in the past, but I might have confused things or misremember. That was the reason behind the *might go quicker* comment up top, maybe that is where the confusion is stemming from?

danio commented

2026-01-29 14:44:46 +01:00

Owner

what an incredibly esoteric piece of functionality.

The document nor the manual describes how to run a persistent rsync daemon that listens "on ssh", and keeping an index up to date as proposed in this issue.

Rather using it mostly just as an rrsync alternative. The ::home thing selecting the "share" and such, but still expecting to start the daemon itself

what an incredibly esoteric piece of functionality. The document nor the manual describes how to run a persistent rsync daemon that listens "on ssh", and keeping an index up to date as proposed in this issue. Rather using it mostly _just_ as an rrsync alternative. The ::home thing selecting the "share" and such, but still expecting to _start_ the daemon itself

Set up rsyncd for various principal pull targets #295