dom0 rsync state

[kennethrrosen]

Can the rsync client state be applied to dom0, in the event a user wished to backup the /etc/ directory in dom0 to the rsync server?

[ben-grande]

Please don't edit your post removing information, unless readers are notified by mail, future readers will have to navigate the edits list to understand what was asked. The question template was also deleted.

The word Answered does not answer your question, we, the readers, don't know what was your conclusion.

Can the rsync client state be applied to dom0, in the event a user wished to backup the /etc/ directory in dom0 to the rsync server?

The client state can be applied with some modifications to the state, the server state cannot be applied and should not be used.

I advise against installing rsync in Dom0, it greatly enlarges the attack surface because rsync filter is much more permissive than qfile-agent.

I recommend just backing up your /etc/ files to /home/user in Dom0 before backing up Dom0 with inspiration on qvm-backup-dom0-provision.

[kennethrrosen]

Thanks @ben-grande and apols for deleting the question template. (I've updated the initial question.) I've written a script that utilizes sys-rsync to backup several nodes, including dom0, and appvm backups using qvm-backuo. From there I've modified the tpl-sys-rsync to include tailscale and binddirs to create dvm-sys-rsync to backup the offline sys-rsync to an offsite server.

Were you interested in the code and including it in the docs, how might I share? I also found that port 1839 was not working -- instead port 839 worked.

[ben-grande]

I also found that port 1839 was not working -- instead port 839 worked.

Fixed the issue of the wrong port. Please check if everything works fine now.

Were you interested in the code and including it in the docs, how might I share?

Can you please do a more descriptive description of the setup, I didn't understand everything. Depending on the way you did it and how applicable it is for other users and my interpretation and evaluation of the setup, I might consider for inclusion.

[kennethrrosen]

1. Modify tpl-sys-rsync to include tailscale
2. In sys-rsysnc /rw/config/rc.local, start tailscale with an ephemeral auth key https://tailscale.com/kb/1085/auth-keys
3. Make sys-rsync template for dispvms
4. Create dvm-sys-rsync with sys-rsync as template and give dvm-sys-rsync network access
5. Run your dom0-provisioner script
6. qvm-backup dom0 and other desired vms to a directory in sys-rsync
7. Sync all rsync-clients to sys-rsync (assumes 30-user.policy is default allow)
8. Start dvm-sys-rsync
9. Rsync from dvm-sys-rsync desired directories (or entirety of sys-rsync contents) over tailscale tunnel (assumes correct setup and config of remote off-site server)

(Tailscale is certainly a niche use case, but it is one way to allow users to backup to issue remote backups to their own servers.)

[ben-grande]

Create dvm-sys-rsync with sys-rsync as template and give dvm-sys-rsync network access

This is wrong and I think I know what confused you. dvm- sounds similar to DispVM, but that is not what it is. dvm- are template_for_dispvms: True, they are template for disposable VMs, they are AppVMs, not DispVMs. The correct setup would be:

• tpl-sys-rsync (TemplateVM)
• dvm-sys-rsync (AppVM with template_for_dispvms: True): template=tpl-sys-rsync
• disp-sys-rsync (DispVM): template=dvm-sys-rsync

The problem with using the default sys-rsync as the template for disposable VMs instead of creating a separate one is that the user will be redirected by default to the sys-rsync qube, so you may upload files by mistake directly to sys-rsync instead of uploading to a disposable based on it. See every other formula that has dvm- and disp- and how I organized them.

I did not provided a dvm-sys-rsync by default because I am not sure of how to do good setup and well documented.

Yes, the dvm- and disp- were chosen by me, but if you have qubes with the same nomenclature and doing different functions, it might confuse you and lead to problems in the future.

---

Tailscale worries me a bit because they have access to your machine and local network (true for all other VPNs), but in your setup (step 9), Tailscale has access to your qubes data because your upload via Rsync instead of doing a backup with qvm-backup.

The other points seems fine if they work well for you.

[kennethrrosen]

I see where we're confused, and the DispVM would not be anyrhing more than a conduit to the data in sys-rsync. You'd not upload there directly; that would be akin to backing up thrice: once to sys-rsync, once to the dispvm, then once to the off-site backup.

Also, I'm not sure what you mean about tailscale. Dom0 preforms qvm-backup and the backups, encrypted by default and with a passphrase, are then sent to the off-site backup.

[ben-grande]

I see where we're confused, and the DispVM would not be anyrhing more than a conduit to the data in sys-rsync. You'd not upload there directly; that would be akin to backing up thrice: once to sys-rsync, once to the dispvm, then once to the off-site backup.

I was warning about the naming scheme of the qubes.

Also, I'm not sure what you mean about tailscale. Dom0 preforms qvm-backup and the backups, encrypted by default and with a passphrase, are then sent to the off-site backup.

Good.

---

Can you give more insights on why someone would choose Tailscale?

What I know:

• It allows you to connect to a node that is not facing the public internet.
• Anyone with access to your Tailscale account can access your machines, this includes Tailscale itself and crackers.
• It is much simpler to use than SSH Tunneling to VPS to be able to access home server.
• It requires some account in the big providers Microsoft, Google, Apple etc or creating your own OpenIDConnect instance. The providers have access to your account because they hold your login credentials.
• Built on top of a modern VPN protocol, Wireguard.
• Requires Tailscale to be running on both ends, same with Wireguard but Tailscale is not available on Debian official repos, requires to use Tailscale repository definition.

It is one way to access your Qubes OS machine from the outside also, this is frightens me, over reliance on these providers because of the challenges of exposing a qube to the public internet:

• Opening firewall ports on Qubes is not that easy without scripting as Qubes OS does not support it to be set by configuration, but requires you to edit the firewall rules.
• SSH Tunnel qube to a VPS requires a paid public server with root access for port forwarding.
• Hidden services on Tor or I2P are possible but slow, considering a large data set.

[kennethrrosen]

It's been the easiest way to connect securely to a homelab. What might you suggest as an alternative?

[ben-grande]

There is no easy solution for homelab as stated previously.

Alternatives that do not have over reliance on third parties such as SSH Tunneling to a public server, Hidden service and opening firewall ports are not for inexperienced users. Port forwarding with a wireguard server is possible, but I haven't done it yet.

[kennethrrosen]

Yes, have considered all and none are viable, though perhaps Headscale is an answer to your concerns of big providers (hello, Microsoft ala Github): https://github.com/juanfont/headscale

[ben-grande]

Interesting, headscale project grew, I remember it from some time ago. It appears that it doesn't support a deb repo, just Deb packages, which is harder to keep uptodate. Anyway, headscale needs to be public facing anyway.

As it seems that a tailscale client can use the headscale servers, a tailscale formula seems suitable. Of course the user will choose if they want to use it for their backups or for whatever reason they want, the installation will be compartmentalized to qubes only pertaining to the same template, so I think it is fine. Although I still believe most users will still use the default mesh network from Tailscale Inc rather than build their own.

[kennethrrosen]

This is wonderful. Thank you! Happy to share my systemd services if those would be of help. At present one offline qube is synced to syncthing used qubes-shared-folders, a sort of hacky workaround to keeping the offline qube safe.