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. Carl K ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Clonezilla-live mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/clonezilla-live
