-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can I request you have a look at Timeshift ? #3
Comments
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.
2. 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.
3. 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
<#3>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKP5QUVR7YGVOM4WGG2VPNLTXAGHHANCNFSM5AEBUNWA>
.
|
Thanks for taking the time to respond. Cheers |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: