... | ... | @@ -63,7 +63,7 @@ To wipe disks on servers without a serial console or management |
|
|
interface, you need to be a little more creative. We do this with the
|
|
|
`nwipe(1)` command, which should be installed before anything:
|
|
|
|
|
|
apt install nwipe
|
|
|
apt install nwipe vmtouch
|
|
|
|
|
|
Run in a screen:
|
|
|
|
... | ... | @@ -101,12 +101,16 @@ When you return: |
|
|
export SHELL=/tmp/root/sh &&
|
|
|
exec screen -s $SHELL
|
|
|
|
|
|
TODO: the above eventually failed to make busybox survive the
|
|
|
destruction, probably because it got evicted from RAM and couldn't
|
|
|
be found in swap again (as *that* was destroyed too). We should
|
|
|
try using [vmtouch](https://hoytech.com/vmtouch/) with something like `vmtouch -dl
|
|
|
/tmp/root/sh` next time, although that is only [available in buster
|
|
|
and later](https://tracker.debian.org/pkg/vmtouch).
|
|
|
2. lock down busybox and screen in memory
|
|
|
|
|
|
vmtouch -dl /usr/bin/screen /bin/busybox /tmp/root/sh /usr/sbin/nwipe
|
|
|
|
|
|
TODO: the above aims at making busybox survive the destruction, so
|
|
|
that it's cached in RAM. It's unclear if that actually works,
|
|
|
because typically SSH is also busted and needs a lot more to
|
|
|
bootstrap, so we can't log back in if we lose the
|
|
|
console. Ideally, we'd run this in a serial console that would
|
|
|
have more reliable access... See also [vmtouch](https://hoytech.com/vmtouch/).
|
|
|
|
|
|
2. kill all processes but the SSH daemon, your SSH connection and
|
|
|
shell. this will vary from machine to machine, but a good way is
|
... | ... | |