search

pigmonkey / cryptshot

Open and mount a LUKS volume before performing a backup with rsnaphot
15 stars 5 forks source link

Continue the script when the volume is already luksOpened ? #8

Closed livier closed 7 months ago

livier commented 8 months ago

When the LUKS volume is already mounted, for instance, when I mount it to check what is is effectively backup (I am in test mode) ; then the script does not go away, stopping with "error 5" at "cryptsetup luksOpen" command. (I added "set -x" at the beginning of the script to see what appends)

Should it be possible and safe to let the script continue with an alweady mapped volume and mount it at the $MOUNTPOINT ? I alwready checked that, after luksOpen, I can mount and look inside the volume in user mode (typically in /media/myuser/UUID) and still having it open with the "cryptsetup luksOpen" command from the script, in root mode.

Is there some side effets that could create ? The side effect that could now appends is that, when looking in the backups in user mode, and if it is time to make a new backup, it fails.

I think of using (your?) backitup script to sheddule cryptshot (and rsnapshot) but to error of letting the backup directory opened in user space is easy to do, and backups need to be donne !

Other ideas, workarounds or real solutions ?

Excuse my english, my real langage is french ;-)

pigmonkey commented 8 months ago

For me, the point of cryptshot is to handle the decryption, mounting, and cleanup. If you have already decrypted and mounted the volume manually, you might as well just point rsnapshot (or whatever backup program you are using) at the mount point directly. Cryptshot doesn't really add anything at that point.

If I have manually mounted my backup drive, it is probably because I am restoring some files from the backup. In that case, I do not want my scheduled backups to execute. They would capture my main filesystem in a liminal state, where I am probably trying to recover from some problem. In this scenario, I would want to finish restoring from the backup, unmount and luksClose the drive, and then execute cryptshot so that it can capture the filesystem in a known-good state.

livier commented 8 months ago

Thanks for your answer and your point. You may be right in critical situations, while I thought of more soft situations where recovering some files in a backups is not a big deal. Security in critical situations seems a better idea.

But, continuing my testings let me meet another difficulty ... After unmonting the usb-drive in user-mode, the backups still cannot be run. The reason is that the sym-link in/dev/disk/by-(part or not)uuid/ has been deleted by the GUI tool that unmount the device (for security remove the device) . The way to make it work again is to remove then reconnect the device. Once more, it is an easy to do error ... Do not know what yould be a good solution

pigmonkey commented 8 months ago

Unmounting the drive will not cause it to disappear from /dev. If the entry is disappearing for you, it means that whatever you are using to unmount the drive is also powering off the USB port.

Personally, I use udiskie to mount and unmount removable media. It handles all the LUKS encryption stuff as well. Telling udiskie to unmount the drive will not result in any change to the drive entries in /dev:

$ udiskie-umount /media/mydrive

But if I tell udiskie to both unmount and power off the drive ("detach"), then the /dev entries will disappear:

$ udiskie-umount --detach /media/mydrive

If you have powered off the USB port, you will have to either unplug/plug it in again, or toggle the power switch on and off. There's probably some trickery you could do in /sys/bus/usb to tell the kernel to power the port back up, but I'd be nervous about messing around in there.

livier commented 8 months ago

I just understood, you helped me. I'm using the kde graphic interface, and when I said "unmount", in fact it also does "detach", without cutting the power to the USB disk, but you still have to reconnect it. Is it possible to include one or more lines that could reattach the device in the event that it's connected - which the user sees - but "detached" - which the user doesn't see - so that backups can be made in this case?

Also, to come back to my wish that backups could be made, even if mounted by a user... I've been using rsnapshot in this way for over 15 years, but without encryption. I've never disabled my crons when I've searched my backups from the day before or from several months ago ... and I've never seen that to be a problem. Normally, the two operations don't fall at the same time of day, and the recovery is for the previous day's files at least ... Why should it be different now that I'm no longer on a desktop but a laptop and I want to encrypt my computer and my backups?

Translated with DeepL.com (free version)

pigmonkey commented 8 months ago

I don't know how to tell the kernel to power on the USB port after it has been powered off. It probably requires changing a value somewhere in /sys/bus/usb.

That you have not had your backups execute while you are in the process of restoring from the same backups is good luck, but I'd rather not depend on it. But more importantly, if your backup drive is already mounted, cryptshot doesn't add anything of value. Just execute rsnapshot at that point.

If you want to allow your backups to execute regardless of wether or not the drive is mounted, I would just make your cron execute something like:

if [ -d /mnt/backupdrive ]; then
    rsnapshot -c /path/to/rsnapshot.conf daily
else
    cryptshot.sh -c /path/to/cryptshot.conf -i daily
fi
livier commented 8 months ago

I don't know how to ask the USB disk to reattach itself using a command or script (automated) without manually disconnecting and reconnecting it. This bothers me now, but when my test phase is over, and I'm confident in my backup system, I'll only have to mount the backup as a user when searching backups, which isn't that often, and will be a minor inconvenience.

I'm used to using rsnapshot as root, whereas to look at backups, being user is enough. As far as I know, I can't see how to manage this in a cron script as you suggest. I had hoped to be able to run the backup script every day, by cron as I used to do, and also just after connecting the USB disk, by an udev rule, but I'm reaching the limits of my competence here. I've also considered using your backitup script to program the cryptshot backup trigger. Do the two go well together? Cryptshot would be run as root, while backitup would be run as a user. This confuses me too. I'm going to sleep on these questions, tomorrow is another day ;-)

Translated with DeepL.com (free version)

pigmonkey commented 8 months ago

In my above example, that script would be run as root. I don't think it would matter if the drive had been mounted to /mnt/backupdrive (or wherever) as a normal user. The root user could still see that it exists and write to it.

I use backitup and cryptshot. I have a script called cryptshot-execute that contains:

#!/bin/sh

# alta
/usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/alta.monthly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/alta.conf -i monthly" -p MONTHLY
/usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/alta.weekly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/alta.conf -i weekly" -p WEEKLY
/usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/alta.daily -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/alta.conf -i daily" -p DAILY
# bishorn
/usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bishorn.monthly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bishorn.conf -i monthly" -p MONTHLY
/usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bishorn.weekly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bishorn.conf -i weekly" -p WEEKLY
/usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bishorn.daily -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bishorn.conf -i daily" -p DAILY

alta and bishorn are two different external drives. They are in different physical locations, so only one drive will be found at a time, depending on where I am. That script is called hourly by a systemd timer. It runs as root, so both backitup and cryptshot execute as root.

Adding a udev rule to call the same cryptshot-execute script after a drive is plugged in ought to be easy.

livier commented 8 months ago

That realy seem to be what I was looking for :-) I should not have tink of putting "lastruns-files" there, and did not think of having a monthly, weekly and daily ones. Just one more think I do not undertand enough ... I did tests whith cryptshot and giveds the arguments in the begining of the script. It works :-) Your suggestion is to pass them in *.conf files ... Seems to be cleaner but ... what is the syntax ? maybe it is a trivial question ... excuse, I'm not a programer. For lanching script by udev .... it will be my next Step. What you help me to do should be IMO a basic precaution for anyone ... thanks for the helps. I will share all this in french ubuntu's forums ...

pigmonkey commented 8 months ago

The config file simply gets sourced by cryptshot, so it is just another way to set the variables.

$ cat /usr/local/etc/cryptshot/alta.conf
UUID="0a0db776-84c5-48e1-9079-cacfbc5de8a3"
KEYFILE="/home/pigmonkey/.keys/usb-alta.key"
BACKUP="/usr/bin/rsnapshot -c /usr/local/etc/rsnapshot/alta.conf"
livier commented 8 months ago

Hello, I'm back. This exercise is a bit difficult for my level of knowledge, and has made me learn a differents things ...:-)

For the moment, I'm left with e few questions:

Finally, I still find it very restrictive not to be able to read my backup volume while I'm testing the scripts. I have to let the operations finish, reopen the volume (GUI typically) to see what happened; then detach it as a user, disconnect and reconnect the usb connection, before resuming my backup tests. What should be the problem to let the procedure go on if we find that the volume is already open, by setting if [ "$?" -eq 0 ] || [ "$?" -eq 5 ]; at line 151 ?

I go for a pause now thanks for your help ;-)

pigmonkey commented 8 months ago

The backup was then launched to the wrong location, on the main disk.

I don't understand how this could happen. If luksOpen fails, the script exits.

I'm also having trouble with the line BACKUP="/usr/bin/rsnapshot -c /usr/local/etc/rsnapshot/xadom.conf"

Looks like that was bug introduced in #6. I fixed it.

I still find it very restrictive not to be able to read my backup volume while I'm testing the scripts.

You can read the volume while the script is executing. Just ls whatever mount point you defined. You only have to allow the script to do the mounting.

What should be the problem to let the procedure go on if we find that the volume is already open, by setting if [ "$?" -eq 0 ] || [ "$?" -eq 5 ]; at line 151 ?

As previously mentioned, I don't want my backups to execute if I have manually opened or mounted the volume. I'd accept a pull request to add an option to allow the script to continue even if cryptsetup returns a non-zero exit code, as long as the option defaults to false.

livier commented 8 months ago 
The backup was then launched to the wrong location, on the main disk.

I don't understand how this could happen.

So much tests I did ! It seems the system had be confused. I had a few time to reboot for the commands became working again. If it hapens again, I tell you.

I'm also having trouble with the line BACKUP="/usr/bin/rsnapshot -c /usr/local/etc/rsnapshot/xadom.conf"

Looks like that was bug introduced in https://github.com/pigmonkey/cryptshot/pull/6. I fixed it.

The script I use has the few lines I saw in the fix. I'm suprised by the fact that difficulty comes when and only when I give the "c" argument in the BACKUP parameter. I now tryed not to use /usr/local/etc/cryptshot/xadom.conf and put parameters inside the /usr/local/bin/cryptshot-xadom.sh script called in /usr/local/bin/cryptshot-execute.sh by the line /usr/local/bin/backitup.sh -q -l /usr/local/etc/cryptshot/lastrun/xadom.daily -b "/usr/local/bin/cryptshot-xadom.sh -i configtest" -p DAILY Same thing, with no -c argument, I get a config error, witch is normal with the default config of rsnapshot. When I give a -c argument, even if it is BACKUP="/usr/bin/rsnapshot -c /etc/rsnapshot.conf" witch is the default (not adapted) config file, it returns Backup program not existing or not executable.

pigmonkey commented 8 months ago

If you are still getting the error "Backup program not existing or not executable", you are not using the latest version. I fixed the grammar of the error message in the same commit where I fixed the bug.

https://github.com/pigmonkey/cryptshot/commit/c410f4b33a25afed0f7519de442f0faaa52b8e1a

livier commented 7 months ago

With your help, anything works now. I Writed an HowTo for all thim, in french here : https://doc.ubuntu-fr.org/sauvegardes_nomades_securisees. Thank you.

pigmonkey commented 7 months ago

I'm glad you got your setup to work. Thanks for writing the tutorial.