Thank you for your comment! It’s always great to hear different perspectives... keeps the conversation interesting.
Even though I framed the article around auditing (a noble goal, and one that makes security folks nod approvingly), the real reason behind this setup is a bit more... humble.
In my daily work, I jump between a lot of different machines. I often find myself crafting commands that I know I’ll need again, but inevitably forget. For a while, I relied on the good old shell history... Until I hit all its usual quirks. You know the drill: history lengths are always either too short or way too long, sessions end abruptly and wipe your precious commands, and each machine needs its own little tweaks just to behave the way you want.
So I came up with a solution: a centralized history receiver, which I wrote about in an earlier post (linked in this one). It worked great... until BusyBox entered the scene. With its stripped-down shell, my previous approach no longer worked.
This article is about how I adapted my setup to work in BusyBox environments. Yes, it could be used for auditing (and that’s how I “sold” it in the post), but my real goal was more about convenience and sanity-saving than full-blown security.
So yep, you’re totally right that there are heavier-duty tools like sudosh2 and snoopy if someone needs serious audit trails. But sometimes you just want your commands to stick around long enough to reuse them without opening a dozen terminal tabs trying to remember where you ran what!
In some Linux distributions, /dev/root appears as mounted at /
Looking at the device node, when it is there, it is just a symbolic link to the actual device. In this small article, I'll try to cast a some light on this less known aspect of the early Linux kernel initialization.
System Engineer currently working for a VoIP devices firm. More than 10 years experience in the Open source and networking field. Passionate in low level firmware hacking and security related issues.