search

tinywrkb / flatpaks

57 stars 13 forks source link

Can I request you have a look at Timeshift ? #3

Closed superuser-miguel closed 3 years ago

superuser-miguel commented 3 years ago

Sorry to reach out to you like this, but Could you look at Timeshift? I tried in the past and couldn't get it working. You seem to have a handle on flatpak development. I'm getting my workspace back so i can help again.

tinywrkb commented 3 years ago

Hi Miguel,

I gave this a quick look, and I'm not sure that the app can be packaged.

  1. It needs root access. If properly designed then only the CLI part needs root access, not the GUI. If so, then there are a couple of ways to work around this, like:

1.a. Only packaging the GUI, getting the CLI from the distro, and adding a flatpak-spawn wrapper for access to the distro CLI. This might bring more trouble, like having to keep GUI and CLI versions synced.

1.b. Packaging the GUI with statically linked CLI, and running the packaged CLI on the host instead of in the Flatpak sandbox (again, with flatpak-spawn wrapper). This requires hardcoding the Flatpak installation path in the flatpak-spawn wrapper to have it execute the packaged CLI, so you can see how this can break. An alternative for hardcoding the Flatpak installation path would be to require the user to copy the CLI or symlink it to a specific location in the host.

1.c. Avoid root operations. This means no BTRFS snapshots, only unprivileged rsync backups, that's if the app has an unprivileged backup mode.

In the firsts two cases, the user will need to copy the Polkit rule to the host or symlink it.

  1. Different file structure in the Flatpak sandbox vs host. This is due to the mount namespace, there's no way around this, but this might not be an issue, depending on the way that the GUI displays paths and files, and how the user select resources to back up. This is not a problem if the user only care about backing up $HOME, external drives, and services data in /var/lib, as these locations won't conflict with the runtime filesystem, and can be mounted into the sandbox.

  2. It uses cron/cronie for task scheduling. Again, there's root privilege issue, and I'm not sure even unprivileged mode can work (so same as 1.c.).

I think that this is a badly designed tool, and not very well-thought-out. Backup solutions that can handle remotes are designed with remote authentication in mind, and operating locally in the remote environment, so there's a protocol in place for communicating between local and remote processes of the backup tool. This kind of applications are more suited for packaging as Flatpak, that's if there's a GUI app.

For example, you have PikaBackup in Flathub which uses Borg. If you need to back up the host OS and not only $HOME, then you can install Borg as distro package or through PIP, set up SSH access, and treat the host as a remote machine.

Sorry that I can help further with packaging the app, it should be handled by its developers who should make the proper changes to support Flatpak.

On Sat, Jul 10, 2021 at 12:20 PM Miguel @.***> wrote:

Sorry to reach out to you like this, but Could you look at Timeshift? I tried in the past and couldn't get it working. You seem to have a handle on flatpak development. I'm getting my workspace back so i can help again.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tinywrkb/flatpaks/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKP5QUVR7YGVOM4WGG2VPNLTXAGHHANCNFSM5AEBUNWA .

superuser-miguel commented 3 years ago

Thanks for taking the time to respond. Cheers

tinywrkb commented 3 years ago

p.s. I see now that UDisk2 DBus API also supports BTRFS. This should have been used by Timeshift instead of directly running the BTRFS utilities as root.