BTRFS subvolume handling through a service menu

[vinnywright]

I was just installing the service menu on the new Neon-user I put on the new-old laptop and discovered/rediscovered that the required "notify-send" is not a package in and of it's self , but a part of "ruby-notify" ,,,, just a FYI for anyone having problems with the notification of actions not being displayed

VINNY

[GreyGeek]

Today's update changed a few things about how BTRFS works. I noticed send/receive was affected. You might want to see if that changes the behavior. Also, something changed with snapshots and maybe some other areas.

In what way?
Before I shut down I took two snapshots, @20280910 and @home20180910, and then used
btrfs send -p /mnt/snapshots/@20180904 /mnt/snapshots/@20180910 | btrfs receive /backup
To send an incremental backup.

Both the snapshots and incremental backups worked as expected.

[steve7233]

Today's update changed a few things about how BTRFS works. I noticed send/receive was affected. You might want to see if that changes the behavior. Also, something changed with snapshots and maybe some other areas.

[oshunluvr]

Exactly! The code change I made will create the snapshot in /mnt/snapshots whereas the send/receive code expects the snapshot to be in /mnt. I guess all it takes is to add "snapshot/" to wherever the source path gets constructed?

No, the send|receive script captures the name and full path of the snapshot when you click on it. Changing the path means you are pointing the script away from the snapshot. That will never work because that snapshot is where it is. In other words, there's no need to manually edit the path when using the send|receive script and it will not work if you do.

Now as far as where you want to locate the snapshot in the first place - not a function of the send|receive script - in the snapshot_subvol script the line:

target=`kdialog --title "Snapshot Name" --inputbox "Enter name for snapshot:" "$filename"`

could look something like:

[FONT=Verdana]target="snapshots/`kdialog --title "Snapshot Name" --inputbox "Enter name for snapshot:" "$filename"`[/FONT]

The problem is if you do this, you won't be able to use the service menu on any other another file system unless, of course, you mimic the directory structure. Ie., if you add "snapshots/" to the script, just having a "snapshots" folder in every btrfs file system would allow it to work.

If you have more than one btrfs file system that you want to use the service menu on, you might want to just enter the location each time you make a snapshot. However, now that I write that it seems like a lot of work. I am re-writing the whole set of scripts right now so let me see if there's a suitable way to have a default location available when taking a snapshot, but still be able to change it on the fly or even change the default at will. That would be a cool feature.

[Thomas00]

Looking at that again, that won't work like that because you're clicking on a snapshot, then giving it a different path, but it's not at that path.

Exactly! The code change I made will create the snapshot in /mnt/snapshots whereas the send/receive code expects the snapshot to be in /mnt. I guess all it takes is to add "snapshot/" to wherever the source path gets constructed?

[Snowhog]

You may just not have all the required compression utilities installed.

[steve7233]

I wonder if my bionic install is bugged since others can get it to install and I can not. It seems that the unzip may not be working as other .tar.gz files do not unzip.

[oshunluvr]

Edit: Looks like a change of path requires more code changes. Send/Receive won't work with a different directory.

Looking at that again, that won't work like that because you're clicking on a snapshot, then giving it a different path, but it's not at that path.

[oshunluvr]

Edit: Looks like a change of path requires more code changes. Send/Receive won't work with a different directory.

OK, I'll look at that when I get a chance. Probably just a small typo. To be clear: send|receive requires a different path for receive but doesn't allow you to change the name of the snapshot. It's like:

btrfs send /<source-path>/<read-only-snapshot> | btrfs receive /<target-path>/

and that's all that's allowed.

JLittle - thanks for the input, I'll play around a bit. Probably won't here from me for a while - I'm in the path pf Florence so I'm busy battening down the hatches!

[Thomas00]

Hi oshunluvr, the service menu looks great and works fine at my end.
I am following GreyGeeks advice with the separate "snapshots" directory hence I added the snapshots directory like below. Seems to work :-)

filename=snapshots/$(basename "$1")_ro_`date +%y%m%d-%H%M`

Edit: Looks like a change of path requires more code changes. Send/Receive won't work with a different directory.

[jlittle]

Sorry, oshunluvr, I started writing this post a couple of days ago, but I couldn't get the askpass mechanism to cancel cleanly. Or covered in muck, for a long time either. Once sudo decided to ask for a password, it insists on two retries, with a few seconds delay between each. I could get the original script to die by sending it a signal (by finding the grandparent id) but still the sudo process insisted on two retries.

Anyway, here's my answers to your questions. My point about the race condition applies to -A as well as -S, and your idea of doing sudo whoami resolves the race condition. Maybe sudo -v would be simpler

Hey JLittle; I'm using kdialog for most transactions. Here's how ...

Sorry, I should have said that I downloaded the tarball and had a look at it.

But I discovered that entering the wrong password didn't doing anything - just allows the script to continue...

IMO you should check $? after any important command that might fail, or put the command in a test. This would have let your script abort nicely.

If I wrote a separate script to capture sudo password, how would that connect back to the action scripts?

The script is run by sudo itself, you just have to define SUDO_ASKPASS to point at it. The work script then is much shorter and simpler, just two lines, the export and the sudo command.

Also, sudo -S is problematic for the send receive service script send_receive_subvol:

echo -e $PASSWD | sudo -S btrfs send "$source" | sudo -S btrfs receive "$target"

The second btrfs command is already using standard input; I suppose the script relying on the second sudo not requiring a password, being within the timeout of the first, but that's a race condition, there's no guarantee of order of execution of processes in a pipeline, other than the i/o on the pipe.

I've found sudo examples where the race is avoided with sudo -v and a sleep, f.ex.

if echo $PASSWORD | sudo -vS; then
   sleep 1
else
   exit 1
fi
sudo btrfs send "$source" | sudo btrfs receive "$target"

With the askpass approach this could become just:

export SUDO_ASKPASS=~/bin/askforsudo
sudo -Av && sleep 1 || exit 1
sudo btrfs send "$source" | sudo btrfs receive "$target"

[oshunluvr]

Well, that's good, but I looked into this a bit, before I saw that, so I might as well mention my conclusions.

I thought that sudo -S would reveal the password via the ps command, but because echo is a shell built-in there is no process whose command line is the echo.

Rather than sudo -S, I think sudo --askpass is nicer. AFAICT sudo -A needs a one word command, though, but refactoring your scripts to use a common password script can be seen as good. Say a script called askforsudo in your bin directory:

#!/bin/bash
kdialog --password 'This task requires SUDO access. Enter your password: '

Then the worker script does:

export SUDO_ASKPASS=~/bin/askforsudo
sudo --askpass [I]whatever[/I]
sudo --askpass [I]whatever else[/I]

If the password is mistyped, the user gets a couple of retries (unless the sudo default is changed). The script can check $? and stop if it's not zero. It could also redirect standard error to catch it into a temporary file and display the errors with a dialogue box to give the user a clue what went wrong. In my example, with default sudo settings, the second sudo won't ask for a password, unless whatever runs longer than the sudo timeout.

Judicious use of sudo -k might be good, too.

Hey JLittle; I'm using kdialog for most transactions. Here's how I ended up handling the sudo part:

This gets the password;

PASSWD="$(kdialog --password "This task requires SUDO access. Enter your password: ")"

This checks to see if you hit "Cancel", then exits cleanly.

        if [ -z "$PASSWD" ]; then 
            kdialog --passivepopup "Info action cancelled" 6
            exit 0
        fi

But I discovered that entering the wrong password didn't doing anything - just allows the script to continue. Of course, the actions that require sudo don't happen, but everything else does - which is annoying because you get a message saying the action is complete when it's not.

So I did this:

        if [[ `echo -e $PASSWD | sudo -S whoami` != "root" ]]; then
            kdialog --error "Sorry, bad password"
            exit 0
        fi

Which seems to work, although it takes a few seconds to fail. There's also no chance to reattempt a password entry but that's a minor issue because you just have to retry the menu entry. I suppose if I wrote is as a function rather than straight linear code I could offer a chance to re-enter the password.

Trying to keep it simple as possible and contained within the ServiceMenu folder; If I wrote a separate script to capture sudo password, how would that connect back to the action scripts?

[vinnywright]

Hmm, strange. Works here and I think also for vinny. I keep my <root> folder mounted for easy access for snapshots and such.

? the "detaild info" ,,,yes it works fine @hear

I do not keep the partition with the BTRFS file system that contains my installed systems and snapshots mounted all the time but if I

sudo mount -t btrfs /dev/sda1 /mnt/test

and go to /mnt/test and use the Dolphin service menu to do any of it's options it works as expected .

VINNY

[oshunluvr]

Hmm, strange. Works here and I think also for vinny. I keep my <root> folder mounted for easy access for snapshots and such.

[jlittle]

I've got this figured out.

Well, that's good, but I looked into this a bit, before I saw that, so I might as well mention my conclusions.

I thought that sudo -S would reveal the password via the ps command, but because echo is a shell built-in there is no process whose command line is the echo.

Rather than sudo -S, I think sudo --askpass is nicer. AFAICT sudo -A needs a one word command, though, but refactoring your scripts to use a common password script can be seen as good. Say a script called askforsudo in your bin directory:

#!/bin/bash
kdialog --password 'This task requires SUDO access. Enter your password: '

Then the worker script does:

export SUDO_ASKPASS=~/bin/askforsudo
sudo --askpass [i]whatever[/i]
sudo --askpass [i]whatever else[/i]

If the password is mistyped, the user gets a couple of retries (unless the sudo default is changed). The script can check $? and stop if it's not zero. It could also redirect standard error to catch it into a temporary file and display the errors with a dialogue box to give the user a clue what went wrong. In my example, with default sudo settings, the second sudo won't ask for a password, unless whatever runs longer than the sudo timeout.

Judicious use of sudo -k might be good, too.