Hacker News Reader

Comment by nexuist | Hacker News Reader

I can one up you:

Coworker was trying to remove node so we could install a new version, so he ran:

rm -rf /usr/bin node

-rf was due to muscle memory, and unfortunately he forgot the space.

That was a fun one to clean up. We were able to use nc because that was in /bin and not /usr/bin, so we used that to pipe curl over through a socket and then used curl to install dpkg + apt, then ran apt update to fix everything and that seemed to work.

That server is still running today, but I'm sure something is still seriously wrong with it. Nothing that affects me though, so I don't care haha.

View on HN

So many questions about this one.

Why would something by in /usr/bin that would be manual deletion? Wouldn't it be in /usr/local/bin? Were they manually deleting a package managed binary?

For that matter, if you're manually installing a component like node with a large set of dirs and you might want a different version at some point (you're more likely to update to a newer major version of node than you are some base library for the system) why wouldn't you put it into /opt/node-X.Y.Z (if not an actual package for the distro)?

We could assume the people weren't as much admins as devs with some minimal admin experience so weren't familiar with some of these common admin practices that have been developed over the years to manage stuff easier and safer, but then why are they root with the ability to blow out /usr/bin and not a user account installing node locally?

It feels like there's some larger problems that even allowed something like this to happen. It's like hearing someone say "my simple webapp connected to the wrong DB server and completely deleted out all the databases there, including the billing one." The first response I have to something like that is "what were you guys doing that something like that was even possible?"

Yeah, I mean, obviously with the right precautions and best practices we could have avoided this. But this was a dev server, so it wasn't that serious if the entire thing got hosed. The only reason we recovered it using nc instead of just formatting the disk and starting over was because the server was physically in the office, and neither of us wanted to drive in (long commute), and we were mildly amused at the prospect of reviving a server over ssh.

When I meant it's still used today; it is, but it just displays a dashboard on a TV screen, it's not actually handling customer data or doing anything critical.

My teammate a couple years ago was writing a script that needed to clear a working directory, so `rm -rf $path/*`. He ran it during debugging and found one mistake - at some point the $path variable came in empty......

Oh I did that in a distro build script where $path was called $INSTALL, but was empty (possibly due to a misspelling of the variable). Double stupidly, I ran it as root and so $INSTALL/lib blew off the system's libraries. I recovered the machine without any rescue disk or reboot or anything, by by copying files from an installation of the same distro. Of course, no commands for copying worked. I think what I might have done is to NFS mount that machine from the other machine, and then doing the copying on that machine.

This is why set -u goes at the top of all my scripts ;)

It always scares me when people automatically add -rf after typing rm no matter what they're doing. How do you even get into that habit in the first place?

If I were to guess, how one might get into that habit is being annoyed by error messages:

"cannot remove 'foo': is a directory"

Just remove the darned object you're given as an argument using the appropriate implementation for its type.

"rm: remove write-protected regular file 'foo'?"

The rules are that if the directory is writable, the object can be deleted. Though you called stat to figure out it's a regular file, you didn't notice the link count: I have two more hard links to the file in the same directory, and one elsewhere. But, yes, unlink it.

I have this bad habit. Because in linux everything is a file, so screw you rm stop telling me i can't delete that directory. Its just a file that points to another directory. Its messing up my flow.

If git repositories didn't need a -f to rm I wouldn't, but its a habit from git repos giving errors.

Starting out with that behavior because it comes up a lot in tutorials, probably. And then not making a typo mistake earlier on to learn the lesson to not do that with every rm command.

I'd probably have that habit if I didn't once delete everything in a /bin directory early on in my learning, and luckily it was in a VM.

Sounds like the ultimate Snowflake Server: https://martinfowler.com/bliki/SnowflakeServer.html

Reply on news.ycombinator.com