Hooks for custom scripts

[avefrandsen]

It would be nice if I could put script files on the bootable drive and have them automatically run at certain milestones, without making a custom bootable

I imagine this would either be a set of folders, one for each event, or a syntax in the configuration file. I set up a bash file, ShredOS runs it at the right point, and waits before moving on to the next step.

Off hand, before and after scripts would be great and I'm not confident any other position exists. NWipe itself could offer some finer steps, but I'm not sure if they would be worth it.

• A specific thing I'd like to do is attach to the wifi after the wipe and upload the records. My station is currently in a very inconvenient location for networking and that's a me problem.
• I'm interested in comparing SMART data before and after a run to identify drives that degraded in the process. Not sure if that will pan out.
• I could make an offloading process where SCSI enclosure lights are used to designate categories of drives, instead of associating drives with their outcomes later.
• In the same I could, hypothetically, pre-screen drives and use enclosure lights to reject drives before the run, maximizing utilization. I might need a degree in linux to achieve that though.

Mainly what this feature would enable is niche enduser customization that doesn't make sense as part of the ShredOS project, without needing to spin up and maintain a custom build.

[DaanSelen]

It would be nice if I could put script files on the bootable drive and have them automatically run at certain milestones, without making a custom bootable

From the context you have given I am going to give my 2 cents to expand it:
If I understand it correctly, you'd like a place on the filesystem or just a storage locations where you can designate scripts to be run.

For example:

./
  scripts/
    pre-wipe/
      do-this.sh
    post-wipe/
      do-this2.sh

Or am I thinking of this in the wrong way?
For example if we designated a specific name in the root filesystem for this. Then we must decide which scripting language we could integrate. Bash, sh, or whatever.

[avefrandsen]

I don't want to be prescriptive because I'm not necessarily the best, or a good person to architect this. The way you describe sounds effective to me, there are folders, put an executable in the folder, everything in the folder gets executed in a specified sorting order.

A script declaration structure in a configuration file could do the same without imposing filesystem structure requirements, and that methodology could allow ShredOS to pass arguments to executables, but I'm not sure what value that would have without direct nwipe integration.

I'm not very experienced with linux but my understanding is file extensions aren't necessary, an executable file should contain a declaration of how it is to be executed, bash, sh, python, whatever is available on the system; I had assumed Bash but the inclusion of additional scripting environments in ShredOS is a conversation other people may have an opinion about, and if it's kept agnostic then binary executables would also work.

One example script would be a pre-wipe script that selects the disks to be wiped and returns that list to ShredOS to then pass to nwipe. Currently I'm having an extremely minor annoyance that something about my system setup is not collapsing block devices from multipath SAS drives. When I include these drives there are always 2 /dev/sd_ devices with the same serial number, and if I include both of these in the job, then every part of the job will be applied to that drive twice, taking more than twice as long as they fight for the head. I could write a script that picks just one instance of any serial number, pass that back, and that's what gets wiped.

[pixeldoc2000]

+1

Maybe it is possible to adapt the way SystemRescue implement this?

https://www.system-rescue.org/manual/Run_your_own_scripts_with_autorun/