I've seen the big boys make a few cockups too. Like not housekeeping log files and running out of inodes on HP-UX systems for example, hard coding usernames and passwords..
Man destroys his business with 1 line of code
- Thread starter morguk
- Start date
I've seen the big boys make a few cockups too. Like not housekeeping log files and running out of inodes on HP-UX systems for example, hard coding usernames and passwords..
I've not gone that far but I've passed usernames and passwords on the commandline before forgetting in *nix that'll show up on PS - fortunately in that case every user was completely virtualised and couldn't see processes for other users.
EDIT: Slightly amusing story regaling a sysadmin about that one once after someone here pointed out the mistake I'd made - they very hurriedly left the room when the implications sunk in...
Last edited:
You are a good person and should feel good.
rm = relocate to mordor
-rf = really and fast
Then you should know ... <insert Sean Bean meme here> thus it should not be possible without a concerted effort...
I reckon it's a troll, but to be fair, pretty much everyone that's done sysadmin of any type has made a reasonably serious ****-up at some point. I don't believe you'd run something like this on all systems before trying it out on a dev box and then a bunch of UAT ones, though.
I don't do much unix admin these days but I've always found it much safer to use something like:
find /path/to/"$foo"/"$bar" -exec rm {} \;
Especially as you can check properly for sane variable(s) beforehand and in testing/debugging you can coment out the exec bit and see exactly what you're going to be deleting. If typing in the console, it saves that accidental hitting of return causing grief, too.
I think I'd have cloned the backup server disks and tried running a recovery program on those afterwards seeing as only the file descriptors would have been removed rather than the data itself?
I've managed to get a wiped system back once after a similar mishap, albeit with a broken database. Damn right mouse click (paste) in a root terminal with part of a script in clipboard. Also pasted some router config in by mistake once which changed the server hostname and messed up the application running on the server, amongst other things.
I don't do much unix admin these days but I've always found it much safer to use something like:
find /path/to/"$foo"/"$bar" -exec rm {} \;
Especially as you can check properly for sane variable(s) beforehand and in testing/debugging you can coment out the exec bit and see exactly what you're going to be deleting. If typing in the console, it saves that accidental hitting of return causing grief, too.
I think I'd have cloned the backup server disks and tried running a recovery program on those afterwards seeing as only the file descriptors would have been removed rather than the data itself?
I've managed to get a wiped system back once after a similar mishap, albeit with a broken database. Damn right mouse click (paste) in a root terminal with part of a script in clipboard. Also pasted some router config in by mistake once which changed the server hostname and messed up the application running on the server, amongst other things.
Last edited:
Soldato
- Joined
- 17 Aug 2012
- Posts
- 6,593
- Location
- Tamworth, UK
Another point I was going to make, he would be doing all this as root, which is scary.
Every script we have written that deletes data requires an extra step beforehand like "touch destroy" which the script checks for to see it was created in the last 10 seconds and then deletes it and then gives a user prompt to make double sure they know what they're doing, so mistakes can't really be made.
Surprised there would be no safeguard in place to stop you doing this. Maybe there will be now
There is:
rm -rf /
rm: it is dangerous to operate recursively on ‘/’
rm: use --no-preserve-root to override this failsafe
I just deal in SQL much safer, the worst I can do is drop a live DB and if there's no backup then that's the other guys fault
Incorrect. The worst thing you can do is insert invalid / corrupt data and not realize until your back-up cycle has expired (day/week/month/year) and find there's no way to realize what is real and what is not, except perhaps three weeks with regular expressions and your apache logs.
Worried about downtime? Amateurs...
Surprised there would be no safeguard in place to stop you doing this. Maybe there will be now
It's difficult to safeguard against people being stupid
He should have had versioned off-site backups, or at least some way that means he doesn't mount the entire backup on the live servers!
Sounded like a terrible setup that was destined to die in the end due to accident, attack or other.
Even my personal data/media has a better setup
Last edited: