Plug-in framework to extend snapper with custom scripts about snapper

[aschnell]

I can make a new release. For the time being you can use compile from master.

Using snapper from the plugins can cause dead-locks. A simple "snapper list" may work. But otherwise there are no documented ways of getting the information you need.

[myth384]

I would like to add that it would be great if Snapper exposes the snapshot location to the script.

[adrianratnapala]

Like @aschnell & @myth384, I'd like to see the black-box opened up a bit. What I don't know is whether the dbus interface is already supposed to do this or not. I'm no expert on dbus.

The examples/ directory seems to show how to write scripts that listen on the dbus interface. But there is no real documentation about how dbus relates to the core work of snapper. doc/dbus-protocol.txt is frankly not very enlightening.

[aschnell]

The scripts should also allow to prevent snapshots, e.g. if a disk is spin-down or an encrypted filesystem is not currently available.

[mbrgm]

I'd be willing to take a shot at this request. Looking at dbus, there seems to be a signal for CreatedSnapshot, so any dbus-capable script could hook into this for a post-snapshot action. Given that you want to do a pre-snapshot check, what about adding two config options:

BEFORE_SNAPSHOT="/some/pre/snapshot/check"
AFTER_SNAPSHOT="/post/snapshot/action"

Both scripts should be passed some parameters, e.g. the config name and snapshot number (last snapshot number for the BEFORE_SNAPSHOT action). Also, the snapshot should only be created if the BEFORE_SNAPSHOT command returns 0.

What do you think about it?

[aschnell]

Hmm, using DBus is an interesting idea. Unfortunately I see a few problems:

• snapperd just sends the signal but does not (and cannot) wait for any reply. So scripts could not stop/delay snapshot creation. There are also not enough signals, e.g. none send before snapshot creation, but those could of course be added.
• snapper has the --no-dbus option. Although it does so far only work for some commands the script plugin framework must also work then.

[mbrgm]

I agree regarding dbus, so what do you think about the config options I proposed? Do you agree on the syntax?

[aschnell]

I fear the syntax is too simple.

Snapper already does call a script for grub but no only during snapshot creation but also during snapshot deletion and creation and deletion of a config, see Hooks.h. I also already have requests to run scripts during rollback. So we would end up with over a dozen of variables in the config file.

I would also prefer a method where packages (e.g. grub) can simply place a script in a directory and snapper executes it. Otherwise many packages will have to modify the snapper configs.

So my idea is that snapper reads all plugin files in a directory. Those plugin files define which script should be run under which conditions. That's a bit like the service files of systemd. E.g.

* grub.conf *
Script=/usr/bin/grub-snapper --number=${snapshot-num}
Condition=post-create-snapshot
Subvolume=/

[mbrgm]

So I guess in this case, Subvolume= is also a "matcher"/condition, right? Should we maybe stick to systemd names like ExecStart= (which we could reduce to Exec=), Before=, After=?

Then we still need a way to express that (in the case of Before=) the specified event should not be executed if the script fails. systemd has Requisite=, but this would involve specifying the event (like create-snapshot) a second time... so maybe we should use something like StopOnFail= with a boolean value.

Edit: One thing I'm worried about though is that users won't be able to easily see which script is executed on which event. There'd also be the option of using the filesystem as an API, i.e. create directories for each hook:

hooks.d/
  |- before-create-snapshot.d/
  |- after-create-snapshot.d
  |- ...

[aschnell]

Yes, Subvolume= should be a condition, either a wildcard or regex.

StopOnFail= should maybe be a Type={precondition/action} since it also defines the order in which the plugins are run. Additional After= and Before= to define ordering like with systemd might be needed in the future.

We should write a proposal (maybe in the wiki) so that we can check if all use cases we have so far are covered.

[mbrgm]

Are you talking about the openSUSE Wiki? I'm not very familiar with it, so maybe you should create the page, @aschnell and we collect the discussed ideas there?

[aschnell]

I was thinking about the GitHub Wiki although I haven't used it before. Please try whether you can edit https://github.com/openSUSE/snapper/wiki/plugin.

[mbrgm]

I was able to edit it and collected the ideas we had so far. @aschnell Maybe you could review the latest revision and check if everything is included?

[kbabioch]

Any news on this? Is this still something to be looked into? snapper is really great as a backup tool with all of its deletion logic. But without being able to send away backups incrementally, it is pretty much useless. This feature would allow for it, so it probably should get some attention, if possible. What would be a good point to start? Not familiar with the code, though.

[mbrgm]

@kbabioch I might be looking into this in the future, as I still would like to use btrfs snapshots as a backup tool, but unfortunately I don't have time for it right now.

[fxthomas]

Adding my voice to the thread, this is a feature that would be very useful.

If that helps someone, I currently use a rather imperfect solution in the form of a systemd unit that I (try to) schedule right after timeline.service and right before cleanup.service.

[aschnell]

A colleague contributed a plugin framework (#728). It does not have all the ideas from this issue but that it's for now.

[johny-mnemonic]

@aschnell I have seen you extended the plugin support a bit since then, thanks.
It is still not released, though. Are there any plans to do so or should I just compile from master?

Also I have seen this sentence in the doc added by you: Using snapper in the plugins is not allowed.
How is the script supposed to get the snapshot description or get the list of changed files (like with snapper status) to be able to decide what to do if it is not allowed to use snapper?

I am asking, because I would like to add script which will backup my /boot when snapper creates snapshot with kernel in the description or in the file list as my /boot is not inside btrfs due to encryption.