Carl Karsten wrote: > Carl Karsten wrote: >> Carl Karsten wrote: >>> I am pondering how to add a safety net that somehow will prevent someone >>> from >>> dropping an image onto the wrong disk. "are you sure" isn't it because the >>> person generally doesn't understand what they are committing to. >>> >>> The story goes like this: Joe service guy figures out that a system needs a >>> new >>> disk. he calls the office and tells someone. person in office grabs a new >>> disk, plugs it into a sata->usb cable, plugs the usb into a linux box, runs >>> a >>> script that drops an image on the disk, unplug, box it up and ship it out >>> to Joe. >>> >>> The slight problem with this plan: the "runs a script" step has to be done >>> as >>> root, and it has the potential of wiping out the wrong disk. For instance, >>> if >>> someone adds a new internal disk to the box, now the usb disk is sdc >>> instead of >>> sdb. or if someone plugs in their iPhone or something. This all kinda >>> results >>> in: person in office needs to figure out what the target device is and not >>> mess >>> up. >>> >>> I am ok with getting them to help (pick a device from a list), but would >>> like to >>> offer an extra level of protection. This is when I start pondering... >>> >>> One idea I had: only restore to an empty disk. "empty" could have a few >>> definitions: no partitions defined, no partition table, no files in any >>> partition. >>> >>> Another idea is looking for some sort of signature: like a file name, or a >>> file >>> with a string in it. and to be over the top, the string could be the date, >>> so >>> that the signature expires after some time. >>> >>> One problem I keep thinking is: The step of prepping a disk has the same >>> risks >>> as dropping the clone on the wrong disk. I have 2 solutions to this: >>> >>> 1. someone else preps the disks, and they are standing by. (this is >>> different >>> than just dropping the clone on them, because there may be more than one >>> image >>> to pick from, and the image may change over time.) >>> >>> 2. person in office uses a 2nd box to prep: maybe a windows box, or >>> something >>> they are more familiar with, and less likely to wipe out critical data. >>> >>> btw - make this an option. I don't want to inflict this added step on the >>> current clonezilla userbase, especially me :) >> I just figured out I can include all of this in the "runs a script" script. >> > > Well, no - I can't exactly just script this, because I wanted to use the > "pick a > device from a list" feature that clonezilla provides. > > How about a hook before or after the "Are you sure?" that calls a script with > some parameters (like the device about to be whacked) and looks at the return > code to decide if it should continue? > > Then I could try various techniques and report back what seems to work. >
I have another idea about this: detect change in "list of drives" (whatever that is - I am actually not sure how linux decides what is/isn't a drive) Here is what works for me: #!/bin/bash read -p "if the drive is connected, remoe it. When it is removed press [enter] to continue..." fdisk -l >fdisk.1.txt read -p "connect disk and press [enter] to continue..." fdisk -l >fdisk.2.txt diff fdisk.1.txt fdisk.2.txt | grep Disk ju...@dell30:~$ ./x.sh if the drive is connected, remoe it. When it is removed press [enter] to continue... connect disk and press [enter] to continue... > Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes > Disk identifier: 0x000ae623 Carl K ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Clonezilla-live mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/clonezilla-live
