Documented host drive killing

[Foglalt]

Hi!

We are using fog system to create and deploy images and now we are planning a mass killing of pcs (all harddisk). Normally we used softwares like Active Killdisk 8well, actually we test it how to and what to. We bought a licence to test. It can create bootable iso to have a semi automatic method. With it I can use pxe environment to boot that from network, it does scripted killing (i hope we can make a properly macroed image to zero interaction; anyone use it maybe? ).

I dont want to use pxe menu manually to start it. Can I somehow tell for to boot something which is in its advance pxe boot menu? Lets say I make an iso, put it in the pxe boot menu as a new entry, test it, then use it like a host task from Fog gui. If so, i can give a pile of pcs to not-trained workmen to systematically put pcs together, boot them, wait till it is killed, switch off, get new ones, etc. I would like to use as less interaction as possible.

With fog i can kill a disk, but i cant have it “proved” (or can i?). With active kill or similar softwares there can be created a certificate (date, serials, etc in a pdf). If i make the mentioned iso to create a file, somehow gather information with fog maybe (with post image scripts or so).

Is it to absurd to do it? have better ideas? I am open to anything. Onlything is needed that i can make those certificates as much automated as possible with as less knowledge of the operating crew as possible.

(As a random idea that bugs me, can i use a premade “image” to overwrite hosts.normally hosts have 1 disk only, but what if they have more…)

[george1421]

First let me get the warning out of the way. Anytime you setup automated disk killing, you also run the risk of killing your over boss’s computer on accident. Doing this may change your job title to “Unemployed”. I’ve had that title before, I can tell you that you don’t want to have that job for very long.

With that said I don’t have a clear answer. But there is a FOG plugin called “tasktypeedit” that allows you to create new “FOG like” tasks you can assign to hosts.

So in theory you could create a new task called Killdisk and then give it a kernel and kernel parameters to pxe boot the iso you created.

If during testing you created a fog iPXE menu and can boot into the iso from the iPXE menu you can use / move the kernel parameters into the task type edit plugin.

[Foglalt]

@george1421 I absolutely have right, but you misunderstood me a bit. Let me clear things up a bit. IT wants to “kill some old pcs” and mass delete their contents. Now this procedure is slow, but goes like this: pc comes from basement storage rooms, identified to delete. Its cables are connected, boot set to usb, from which a scripted killer software runs to kill disks. Notes taken (old school, paper etc), then documents created later to achive about the process.

We are looking for a better method, something like this: pcs are gathered, identified and so on, all connected to network. Then task is given, maybe over pxe environment, and crew (DONT have to be IT staff, ppl who can connect cables, watch screen to see if it is done) wait, disconnect pcs after work, then go for another pack of pcs.

We dont want it like this: registered pcs in fog as hosts and at a certain time select for deletion and commencing it. (actually we dont have permanent hosts in fog database, only lab computers. others are just regged only for imaging purposes, then removed).

Accidental “boss pc kill” can only be done if registered that mac, set task, reboot and NOT NOTICING it is not started as task, wondering what happened, then forget it without deletion of false task. and later boss pc turn on, disk killed. No, it is absolutely not happening this way

Still you see risk in this theory or is it cleared? (btw I appreciate that you wanted to point a possible problem source!)

[george1421]

@Foglalt My initial comment is a bit of joking and serious point too. Just because you can doesn’t mean you should.

Now putting the nonsense aside.

I think I would still go with an iPXE menu option to pxe boot your kill disk iso image. You can place it on the advanced menu or on the main menu, just set the option to only display this menu for unregistered hosts. So the only way this menu item can be selected is on an unregistered host, or you need to unregister it (from the ipxe menu) before you can kill the disk. If you use the iPXE menu the IT Tech must be in front of the machine and have access to the machine to select the kill disk menu.

[Wayne Workman]

I’d strongly recommend against automating the destruction of disks for exactly the reasons that George outlined.

For the iPXE solution, this has already been accomplished here:
https://forums.fogproject.org/topic/4791/fast-wipe-in-advanced-menu/9

To add an entry to the boot menu for full wipe it should be this:

:MENU
menu
item fog.fullwipe FullWipe in Advanced menu
item return Return to main menu
choose --default fog.fullwipe target && goto ${target}
:fog.fullwipe
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=${fog-ip}/fog consoleblank=0 loglevel=4 capone=1 mode=wipe wipemode=full mac=00:00:00:00:00:00
imgfetch init_32.xz
boot
:return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || goto MENU

[Foglalt]

@Wayne-Workman Actually no full automation is needed. I just want to hand out job to ppl who are not needed to param a util properly with 10 or so options every time. Many occasion to mistype, etc. pxe menu is used, but the selected software needs tuning. I was just wondering about a documentable method utilized maybe from fog’s pxe environment. And maybe do some documentation with the process automated.

thx for cooperative thoughts anyway

[Junkhacker]

how about this:

1. you make an image and called it, for example “!KilldiskTask!”
   this image is just an empty formated drived that you’ve uploaded for the image. it exists only so that this is a valid imaging task
2. you create a postdownloadscript that checks if the image being deployed is “!KilldiskTask!” and, if so, retreives the killdisk linux terminal application from the server (you could put it in the service/ipxe directory on the server, so it could be downloaded just like the kernel and init files) and run it with the appropriate command line parameters (i have not tested that this program will work within FOS)

have your people

1. quick register
2. on reboot, task with a quick deploy of “!KilldiskTask!”

doing it this way, you have a hardware inventory of each computer, and a log of them getting the “!KilldiskTask!” deployment

[Foglalt]

@Junkhacker I have such ideas, partially went through it to see if the concept is working or not. thx for comment maybe somehow i will figure out a solution. With our situation the main issue is to have a document after it with deletion (like vertificate), and make it as easy as possible to have untrained staff to use. “premade image” is a “light” solution. fog’s disk delete feature is a “semi-ok” solution. active kill disk and such softver is the ideal (only it is not properly automated in a mass way).

If i have enough free time (non-existent in my dictionary) i will find the proper way.

[Junkhacker]

@Foglalt said in Documented host drive killing:
in the postdownloadscript stage of my method, you could have the killdisk program generate the certificate and upload it to the fog server

[Foglalt]

@Junkhacker i will inspect the postdownload script section usage (well, documentation search in some topics is hard for fog system, for me at least). but atm we have a lot more disturbing problem, mystery that keeps me away from sleeping. topic is “missing image”

[mitzayapa]

This post is deleted!