Live data from Hacker News

The classic Unix horror story

lug.wsu.edu

31–40 of 54 posts

Re: The classic Unix horror story

#31
post #3

I still remember my "rm -fr /" episode after almost 20 years. It was slightly different, something related to chmod'ing some files under /etc on an AIX server: $ cd /etc $ chmod 600 some_file * # instead of some_file.* oops... Thank God for boot diskettes.

I was playing with FUSE, and had managed to mount a loopback filesystem. And then, for some ill-considered reason, I tried to delete the directory that I had mounted it inside. I managed to Ctrl-C it before it ate any files in /home, but I still had some nasty cleanup work to get the computer back in working order again. Thank god for LiveCDs.

In the same spirit, I once removed a chroot tree, forgetting I bind mounted /etc into it.

It took me half a day to recover from that.

Another one, even more stupid, is to recover a "backup" of /var, done without the proper rights to it. I noticed the problem after a lot of weirds errors cropping in. This one I did not recover - after a few hours, I ended up deciding that reinstalling linux on my machine would be faster and more reliable.

Re: The classic Unix horror story

#33
While part of a team of students at a hacking competition I was VNC'ed into an owned 2003 server, I was trying to get to the network settings properties menu, when my VNC session lagged and I clicked at the same time that my mouse reached the Disable interface.

Yeah ... I didn't live that one down, lost my team some points.

Re: The classic Unix horror story

#34

Earlier quoted context omitted.

My marquee move is to shut down the ethernet interface of a box I'm SSHed into.

I used iptables to block all incoming traffic. While SSHed into the server. Thankfully, Linode's out of band console works (slow and painful, but it worked).

I did this as a result of following a (poorly-conceived) iptables tutorial.

'Step one: configure iptables to deny traffic by default: iptables -P INPUT DROP'

There's also the time that I learned why you should think twice before setting a default policy of DROP or REJECT - iptables -F will clear all rules that allow you in, but not the default policy that keeps you out.

Re: The classic Unix horror story

#35
post #9

I've never actually been bitten by rm (or done anything remotely this badass) but in college I did have a bad Unix moment: Late at night, I was tarring up a finished project right before emailing it to my professor. I ran: tar -cvf *.cpp *.h something.tar instead of: tar -cvf something.tar *.cpp *.h It happily wrote most of my project into a tar file on top of the first source file, then complained that something.tar…

Man, that is scary. These days with Dropbox and github and TimeMachine, I rarely worry.

Re: The classic Unix horror story

#36

My terrible UNIX, or really SunOS/Solaris moments have been: o typing 'halt' into the wrong xterm, shutting down well planners o and likely on the same network, jacking up the NIS+ on Solaris It's been a constant itch that I never did manage to understand what I was doing wrong, such that NIS+ wouldn't restart correctly.

kill -9 0, forgetting of course that I'd su'ed. Long drive to the colo.

Re: The classic Unix horror story

#37

frequent automated offsite backups are your friend

I once did the old "rm -rf *" in my home directory in college. It wasn't a system I used a lot, so I wasn't missing much, but I went ahead and asked for a restore from tape anyways. I didn't hear anything for 3 days. Finally I caught our head sysadmin in the hallway and asked about it. He said, "the good news is: we're getting a new backup system." The bad news? "Your files are at about gig 7 of the 6 gig tape."

Even this week I've reminded people at work that if you don't test your backup (and restore) system, then you don't have a backup system.

Re: The classic Unix horror story

#38
I don't agree with the following comment:

"Great programmers spend very little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. "

I mean so... who's writing the code then? Who's writing the original code? I would call a clever programmer a great programmer. Just clever. and sometimes clever can get you into trouble. But just sometimes :)

Re: The classic Unix horror story

#39
post #38

I don't agree with the following comment: "Great programmers spend very little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. " I mean so... who's writing the code then? Who's writing the original code? I would call a clever programmer a great pro…

They write code for things they can't find an existing solution. Its not that they don't write any code, they just don't write very much, and what they do write is good enough to be found and used by others.

Re: The classic Unix horror story

#40
I might have misunderstood the story, but if this happened to me today on my gear I would simply turn it all off, connect that half-erased hard disk to another machine, mount it, and pull all the data off. And only after a lot of googling to see if some of the lost files could be "undeleted".

Salvaging the disk by recreating a minimalist system on it is heroic and hacky, but was that the only way?

Post reply on HN