What is the most damage (of whatever kind) that you have ever caused with a single mistaken/mistyped/misguided command line? I deleted a production system database by mistake a while back, for example, but I was lucky (i.e. backed-up) and there was no permanent data loss, lost money, property damage etc.
Most importantly (for votes), what do you do to make sure it will not ever happen again?
In SQL server, on a production system:
update customer set password = '' <enter>
The most recent backup was like a week old.
To mitigate this, I now usually write a select statement first to make sure I've got the where clause correct, then go back and edit it to insert the set clause and change the statement to update.
Biggest mistake? Thinking I had set two variables when I had not. So rm -rf $VARIABLE/$VARIABLE2 became rm -rf /. FreeBSD has recently updated their rm tool so that rm -rf / is not possible anymore precisely because of this mistake!
Omitting the -r from a shutdown command. On a remote server. On the other side of the country. With no IT staff in the remote office.
We've all done it, it's almost like a rite of passage at this stage.
shutdown -h now
meant for the local workstation, but typed it while logged via ssh on production server. Since then I always have hostname in my $PS1.
On a VMS system, I had been using the ASSIGN DCL command to assign logical names, and I wanted to RECALL a previous ASSIGN command line. Now, in VMS, you only typed as many characters of a command to make it unambiguous. So I intended to type
REC ASS
but I accidentally typed
REQ ASS
instead. REQ was sufficiently unambigous for the REQUEST command, which broadcasts the argument to everyone with operator privs (which was everyone in IT). So the entire department received my broadcast message which was simply "ASS".
On a Solaris system: "killall dataLoader".
'dataLoader' was an app I was working on. On Linux, killall works like pkill. It sends a signal to processes that match a string given as the argument. On Solaris, killall trys to kill everything on the system the current user can kill. I was root.
Once, many many moons ago, I needed to find a particular executable but couldn't remember the complete name of it (but could remember a few of the letters). So I figured I'd check the /usr/bin directory with something like this
rm /usr/bin/i*g*
Strange. Nothing returned. Figuring I just had misremembered the second letter, I tried again with
rm /usr/bin/i*
Again, nothing. After doing the same with /usr/local/bin, /usr/sbin, and anything else I figured it might be in, I realized I'd been mistyping the 'ls' command.
Don't quite know where the brainfart came from, but it's definitely not a mistake I ever made again.
Trying to change ownership of everything in a directory, including dot files, with:
chown -R user * .*
Guess what that does?
Meant to destroy /dev/sdb, fortunately I had a good up-to-date backup
dd if=/dev/urandom of=/dev/sda
On one of our data production server, one of my roots typed:
chmod -R 777 /
Because he was getting permissions error with some scripts...
Shortly after that, his private key was removed from all servers and he took care of the 1TB data restore on the data production server...
select * from <File1> join <file2>
On a production box. Note the lack of an on clause. :-) Both tables were multi-million row tables, and this was on an AS/400 in the mid 90s where once the SQL was running you couldn't kill it.
Many years ago I was at home coding up some stuff in php while working on a project with a buddy of mine who was the maintainer of the project. We were IM'ing one another in a collaboration effort. We always banter back and forth in play.
I was trying to get ssh-agent to work properly on my machine while we were having a religious war of Perl vs PHP. Then I mentioned something about ssh-agent needing to be eval'ed (not sure why I said that). So then he sent me this message in an effort, so I thought, to help me with my problem (bear in mind that I was su -'ed to root):
\# eval $(echo ssh-agent |
perl -pe 's/h-a/m -r/' |
perl -pe 's/^ss/r/' |
perl -pe 's/gent/f \//')
WARNING! DO NOT RUN THAT COMMAND!!!
IF you remove the eval and run the inner command by itself it is:
rm -rf /
It took me all of 4 seconds to notice what was happening but the damage was already done. I had to reinstall my OS. Fortunately, nothing of my work was wiped out except some stuff in /etc iirc. He had a HUGE laugh when I sent him a message of horror asking why he did that. We are both long-term systems engineers. He didn't think I would run it and would be more careful to check it before simply c&p'ing and I just trusted him so I didn't even consider he was playing around. Needless to say, this little story comes up all the time between us. So, I decided to immortalize it.
How have I mitigated this from happening again? I trust no-one!
Another less interesting story is a couple of years back I was doing some work on a mission critical box at work. I had a few terms open to different machine. I needed to remove some superfluous stuff in a directory. Well, I got lost in my terms and accidentally rm'ed . in my local dir but on the wrong host (wrong term)!!. I executed the command in /var/lib/mysql instead of /tmp on the application server (different term). Needless to say, I wiped out the production database. Fortunately, we had a warm standby that we flipped to while me and a co-worker rebuilt the primary from backups and the standby. That took about 18 hours to do.
Mitigation: more careful about what windows I execute commands in before executing them.
My erm favorite was when I was at university. I was building an application (I don't recall what) and as I wasn't root I had built it with
PREFIX=~username/usr/local
So I could install it to my home directory. Unfortunately it installed into
/home/username/src/app/~username/usr/local
instead. Naturally to delete it as start again i executed
rm -rf ~username
In the source directory.
I wondered why it was taking so long....
:-)
However my worst one was when I was working with a solaris workstation and after getting it all setup we wanted to wipe the configuration ready for live config. So I executed
sys-unconfig
Agreed to the warning message and instead of the machine rebooting and going back to "factory defaults" The xterm window simply said
connection closed by foreign host.
Moral of the story Don't ever leave a root shell open on another host! EVER!!
I think the most stupid thing I ever did was to remove the default route on out external facing firewall cluster - whilst vpn'ed to my desktop over a hundred miles away.
Fortunately it was in a period designated as planned downtime (just in case), but that did not save me the 200 mile round trip to go and reconfigure the firewall onsite. It also did not help that this took out our internet exposed production systems for the duration of my travel and subsequent fix.
We all know the definition of a nano-second. An ohno-second is even smaller, and is the time between hitting 'enter' and realising your mistake.
First of two...
On a Solaris box we had a tar backup of an AIX machine..
One of the Developers typed:
tax xvf AIX_Backup.tar
Of course the paths in the tax were absolute and we ended up making a new distro of unix... Solarix... The only problem with the distro is that it did not boot :(
the short version
#/bin/bash
$0&
$0
I once wanted to delete a bunch of files in a directory.
del *.*
The computer then said "Are you sure? [y/N]" I thought "OF COURSE I'm sure, I wouldn't have typed the darn command in otherwise! Sheesh stupid computers grumble..."
Y <enter>
C:\Windows>_
Um... WTF? Did I just erase my windows directory?....
undelete *.*
In those days of small hard disks I knew what every file in c:\windows was for and what its name was, but even after undeleting everything the system was never the same. I gained a little bit of respect for the "are you sure" prompt. Just a little.
Story told to me:
Another branch called because their local PBX had some issues. After some investigation, we learned that they updated their server, but not their Asterisk configuration. So, the admin decided to instruct the branch guy to redo the configuration.
Admin: "Ok, now, type rm -rf /etc/asterisk"
Guy: "Ok."
Admin: "Now, type cp /var/..."
Guy: "Wait, it is still running..."
Admin: ???... !!!
source ~/.bash_history
My intention was source .bashrc, but I was too hasty with tab-complete...
rm -rf / some/path
instead of
rm -rf /some/path
Luckily it didn't happened to me ;-)
had trouble with network (on a remote machine) and just wanted to restart the interface
ifconfig eth0 down && ifconfig eth0 upp
Nowadays, I make sure someone is near the machine before trying things like this (iptables is a good candidate as well). And when nobody was there, I once typed
sleep 600; reboot
into another (screen) terminal, so that it would reboot if I could not ctrl+c the command within 10 minutes.
I learned from that mistake as well (ctrl+c the sleep will run the reboot) and now I use
sleep 600 && reboot
which will enable me to ctrl+c it.
ifconfig eth0 down
Oops, I'm on the external side of eth0. The webserver is on the other side of the world, in a locked room. With no network access to login or reboot. Crap.
Something along the lines of this:
sudo dd if=/dev/zero of=/dev/sda
I meant sda4. I wiped the entire disk, not just the partition :-(
XCOPY is a powerful beast - merciless in it's execution and retarded by the fact that its command line args go in reverse from Window's COPY and UNIX's cp.
A couple days ago I accidentally wrote:
xcopy src \path\to\a\new\nonexistent\directory
XCOPY was kind enough to overwrite my src directory with... nothing! And it didn't bother to put the old files in the Recycle bin either.
Oh, and it turns out that XCOPY actually overwrites the same sectors on the disk instead of allocating new ones. I've tried 3 disk recovery programs, and the best one could only recover 3 of the 10 files lost. Of course those 3 files were only vshost.exe and its pals. Swell!
A free cookie to anyone who can tell me why I was an idiot for trying to remove all hidden files and directories thusly:
rm -rf .*
While cleaning up my home folder on a production webserver, I forgot that I had symlinked the server's web root to a place in my home folder. Not thinking, I ran an rm -rf on that folder and next thing I know, people are calling that the web site is down!
OOPS!
I was once comparing data in two folders and ran rsync with the -d option (delete files on destination that are not on the source). And then I switched around source and destination when I ran rsync. That deleted all the new files, that I wanted to backup. Now I learned running rsync with -n (dry-run).
rsync -trvd --stats --progress /destination /source
I had no backup.
Once upon a time (probably System III, but it was a long time ago), it was possible to create a file named * by using the right shell quoting. When I found one in my home directory, I had typed rm * and had my finger on the return key when something made me hesitate and think about it...
Creating such a file for other users was a common prank.
If the file is sitting there in a directory, that is a tough one to mitigate. The reflex to just type its name exactly as ls just displayed it is pretty strong.
The other (less harmful) prank was to name files with trailing white space (or only white space) which were much harder to remove...
Due to some bad experience with general JBoss flakiness after a restart, I like to clear JBoss' working files before a restart. I would normally do:
# cd /var/cache/jboss
# rm -rf tmp/* work/*
In order to protect myself from typing any of the many possible disastrous mistakes, like:
I make the last command:
# sudo -u jboss rm -rf tmp/* work/*
Since the JBoss user would find it difficult to remove any critical files that don't belong to it.
I never actually made that mistake, but I'm safe in the case that I do.
Delete the payroll database... :(
rm PAYROLL
Had intended to delete a text file of a similar name, PAYROLL.txt. Spent the rest of the afternoon restoring the previous backup and then running a series of audits to rebuild the payroll based on other supporting tables.
All in all, it was a pretty freaky experience (both the loss and the recovery)... :)
Piko
When removing a config snippet I had just added into a core mpls router I was doing it by typing
no
then pasting in the line to remove. Unfortunately I had the wrong line in my paste buffer. I thought I had
vll id X
I was wrong and I still had the previous command in the buffer. The last thing I saw from that router before it stopped responding was
router(config)#no router mpls
Thankfully we had out of band management so I was able to get back in and restore all the mpls config from backup.
As for making sure it never happens again. First I argued with upper management that we should have automatic service deployment like we did for the switch network and I made sure "router mpls" never ever went near my paste buffer again. I always typed that line in by hand.
% dd if=linux_boot_floppy.img of=/dev/hda
instead of:
% dd if=linux_boot_floppy.img of=/dev/fda
/dev/hda == hard drive
/dev/fda == floppy drive
First thought was, "Oh wow, that was fast". Second thought was, "Oh ****".
I ran cleanlinks in my $HOME directory. Apparently, some links should stay dirty and some empty directories matter (say the ones in your mailbox folders). Feh.
Thinking: "Before i do this upgrade, I'd better be safe than sorry, and take a backup."
Writing: tar xzvf backup.tgz /path/to/production_site &
... time passes
... checking size of backup.tgz
Thinking: Why is this file not growing?
... thinking some more
... time freezes, realising that a week of development on the site is gone, overwritten by an old backup.
In teaching a new Junior Admin how to do something, he made a typo and we didn't catch it before he hit enter. So instead of:
kill -9 <somepid>
We did:
kill -%9 <somepid>
On a Solaris 7 machine, this apparently translates to "halt". (I could be mis-remembering the exact typo, but a % was involved).
The machine was a three hour drive away at a client's site. We had to call them and beg them to switch the machine back on.
I once copy/pasted some "bash magic" script which I didn't understand from a slashdot comment, which had no warning and no comment other than that one liner. That's just stupid, I know.
It turned out that evil lines spawned bash processes in a loop which rendered the server completely unresponsive. Luckily it was based on XEN and I was able to reboot it using xm reboot (calling data center to do manual reboot is always messy). On the other hand, I didn't have access to dom0 instantly.
Lesson learned - don't copy/paste stuff you don't know :)
I used to be a linux lab admin, and one of the students was trying to get her Joomla install to work. She needed to add execute permissions to one of the files. Not knowing much, she was going to do:
chmod -R 777 /path/to/joomla/
Except what she did was:
chmod -R 777 /path/to/joomla /
Turns out that her complete filesystem(/etc/passwd, /etc/shadow...) was 777.
When you don't specify all the modes, it presumes you want to remove the permissions that would go with them. So everything was now mode 0777(i.e. no sticky, set user/groupID). There's a lot of important stuff that's set-uid, like su.
In a DOS prompt I typed the following command at my computer
C:\deltree /y *.*
Now I just select with the mouse what I want to delete and delete them.
Working for hours and hours editing configuration file to configure an application, only to confuse the configuration file for a temporary file, and delete it. Damn auto-completion (and my own inattentiveness!)
Back in dark ages of DOS there was a utility called, as far as I remember, killtree, that deleted a directory tree without any confirmation.
I then had a keyboard that had the \ under the Return.
Under Norton Commander I wanted to delete a directory tree in c:\ I had the selection over, so I type:
killtree Right Ctrl + Return
Ctrl Return combination was used to insert file/dir name under the selection into the command line.
The problem is, instead of Right Ctrl, my finger went to the \...
Most annoying mistake I remember doing was a some years back when hardware where expensive and we often used software routers/firewalls rather than hardware ones. One night we got hit by some pretty bad DDoS. Trying to debug this/figure out what I could do, I logged onto the main router and started doing tcpdumps, however the system were so insanely unresponsive that I figured Id better just drop the firewall rules so that I can hopefully get some sorely needed cputime. So I typed;
ipchains -F
Problem is, default policy of all chains were drop. Had to call up my boss in the middle of the night, take a cab over and fetch a keycard then get onsite and manually reboot the router.
I know someone who wrote a custom tool to delete a tree recursively and tested on a network drive that did not return ".." as one of the "find next file" entries.
The first time it ran on a drive that did return ".." it backed up to the root and wiped clean the volume.
This was a LONG time ago and I was a real newbie to PCs being primarily a Mac tech. But a big Pharma company in NJ was migrating from WIN 3.1 to Win 95.
Our instructions were to boot from our special network boot floppy, CD to the C: drive and delete everything on the drive with your standard DOS command to do so.
I had done a dozen of these with no problems till one where I forgot to CD to the C: drive. Seems the floppy left your current directory as the network drive that held the install files that you were supposed to just copy to C and then reboot to run.
I think you can see this one coming. I neglected to change directory before issuing "DEL STAR DOT STAR" and the brilliant sysadmin who had set it up made that share R/W to EVERYONE and bang away goes all of the files that were needed by about 30 techs swarming over the building trying to get several hundred PCs upgraded over the weekend.
And to make matters worse, they had no backup.
So everyone went home with no idea of who did this grumbling about lost overtime. And a few SysAdmins grumbling about having to rebuild the install share from scratch.
Needless to say I was "busy" next weekend when they tried again.
Easy easy... hitting ENTER when my screen has been scrolled up in order to return it to the command line. I've ran the wrong command a few times doing this. I've gotten in the habit of hitting CTRL-C instead.
shutdown -h now on production database system I was connected via remote ssh tunnel. I suspected something was wrong when instead of shutting down my own box I got the message "connection closed by remote host" ;)
as root:
find / -type d -exec chmod 755 {} \;
find / -type f -exec chmod 644 {} \;
I ended up rebuilding the box.
... true story.
We had a FTP script that would update directories which housed our Client's reports. The script looked like this...
ftp www.ourcompany.com
cd <ClientsDirectory>/
put *.html ( including index.html )
So just what happens when <ClientsDirectory> does not exist?
You get the client's index page as your companys home page... Opps
Ubuntu 10.10, I had only 3gb left on my partition so clearing up files.
I thought, ah well, might as well remove old kernels (GRUB screen was becoming too big too).
sudo apt-get remove --purge 2.6.28*
The asterisk was a little bit... greedy (though I still don't know how it managed to match 2.6.29 and .30).
Epic freakout, didn't dare to ctrl+c (what's worse then deinstalled kernels? that's right, semi-deinstalled kernels). Let it run and reinstalled latest kernel. I even opened an edited document in gedit so it would block any restart (I know, I know...).
and now for a Win XP commandline complete screw up :
C:\Somedir> cacls.exe * /r Someuser
did something much worse than expected
I wanted to remove all "~" backup files (passwd~, group~, resolv.conf~) and on a Swedish keyboard you need to press the ~ button and a space to write a "~" and what I did was:
$ rm * ~
In /etc
Good stuff here. I've done a LOT Of them. To avoid the missing WHERE clause in SQL, I now use: alias mysql='mysql --i-am-a-dummy'
An interesting one was while updating a remote server: mv /home /home_old && mv /home_new /home mv /var /var_old && mv /var_new /var mv /lib /lib_old && mv /lib_new /lib
It seems that Linux stops running (or booting) when /usr/lib dissappears. Remote servers now have either an IMPI card, or a serial console lnk to another server, plus a boot CD in the drive.
using joeware ad tools I had a script which was supposed to change a user account from 512 (active) to 514 (disabled user) in the useraccountcontrol attribute.
the command was:
admod -b "userdn" useraccountcontrol::514
but I was also attempting to redirect the output by putting a 2>nul on the end, but I missed the space and the 514 became 5142 which caused AD to change user accounts to Computer accounts, this was run on a the production domain against all accounts.
Easy one in - and I've done it more than once:
Del from Some_Table
without any qualification. Always do a 'select from' first now to make sure I've got the correct data.
DROP TABLE [dbo].[WRONGTABLEHERE]
Then the immediate feeling of terror as soon as I executed it.
I was in / instead of another directory and performed the command below.
rm -Rf *
By the time I canceled the command, nearly all the /usr/ directory had been removed.
On a Windows NT 4 domain controller back in the day:
C:\WINNT\System32>DEL *.*
I had been working in a subfolder (WINS I think) and was expecting to delete that folder, but wiped out most of System32 instead.
How do I make sure that never happens again? I do things a little slower these days.. double check that command line before pressing enter.
Back in the DOS days I was trying different commands to see what they do. I knew enough to not mess with fdisk or format but I saw this neat looking command called recover.....wiped out the entire machine....Taught me to never run a command unless you have some idea what it does.
After 12 hours of weekend work, wanting to check IP address of server hostXYZ and while being logged in to a HP-UX MC/ServiceGuard cluster node, I typed in:
hostname hostXYZ
I was immediately covered in cold sweat. :) Luckily I managed to revert back to old hostname before ServiceGuard even realized what happened. :)
As root : rm ./* on a Tru64 machine. Yes, in "/". Yes, on a production machine.
I did not do this - some other jerk did.
The (longish) story of recovery is here: h t t p : / / slashdot.org/~Noryungi/journal/212909
What did I do? Nothing. Another, even bigger idiot (CTO) insisted all his programmers needed to have access to the root password. (sigh)
As a normal user : rm -fv ./* in my /home on a Linux machine. Pressed Ctrl+C fast enough to prevent huge damages. Thanked Cthulhu for backups for days afterward.
The rm -rf * command seems to be a pretty common problem. I had network mounted drives though and the command deleted the contents of all of them too. Once that was done it deleted the Unix operating system. UGH!
rm -f /bin
instead of
rm -f ./bin
as root (of course) on an old FreeBSD system. Luckily all the commands in /usr/local/bin and /usr/bin sufficed to copy binaries from the install CD /bin and unhose the system.
Today I had a weird file I was unable to delete so I went in the terminal. The file was begining with a " ? " so I did :
rm ?*
Which erased every files except folders. I then remembered that " ? " mean any single characters so it was like I did :
rm *
The most recent amusing mishap was a colleague installing a new Solaris 10 zone. The first time he'd randomly selected the swap device and the zone installed and ran quite happily. The second time he picked the device that happened to be the root drive...
The box didn't come up again. Oh, and it was a production system.
I was working for an Internet marketing company as the systems / database administrator. I had given a fellow employee (now good friend) read/write access to a web advertising system we were building - a sort of DoubleClick.net platform style thing but just for us, so we could manage all our ads across various networks. We were writing a new reporting module to gather data on something or other and he was playing around and did the classic SQL newbie mistake:
update advertisements set url='something'
Without the where clause. So that afternoon, when the boss came in and asked "why are all of our banner ads pointing at the Tragically Hip??" I really had no idea... the Hip being a popular Canadian band, my colleague had basically sent tens of thousands of dollars worth of ad space that we had purchased on behalf of our clients to the website of his favorite band on accident. We were both able to keep our jobs, though groveling was involved.
I got really good with Netsaint (the predecessor of Nagios) after that, and learned not to give SQL newbies access to production.
A colleague decided to be funny and did:
net send /DOMAIN *my_username* Hey How You Going!
Unfortunately, instead of ME getting the message, the whole floor gets a popup window saying:
my_username Hey How You Going
Luckily messenger stuff is blocked at the floor router, although a manager did run out to abuse me for "wasting company resources!"
A friend of mine works on a classifieds site running on Windows / IIS. The site had lots of image files stored on their web server's disks that were no longer referenced from their database so he decided to write a quick cleanup script. He wrote a small program to generate the script, something like this:
List<string> imagesInFileSystem = Directory.GetFiles(imageDirectory);
foreach (string file in databaseImages) {
if (!imagesInFileSystem.Contains(file)) {
Console.Out.WriteLine("del " + file);
}
}
And it generate the following output:
del c:\images\image1.jpg
del c:\images\image2.jpg
...
etc
Which looked pretty good. However when he ran the program most of the images for the site were deleted! He forgot one thing: the server's filesystem is case insensitive but his check against the database wasn't.
The sales guys had to spend the next couple of days calling up people to get them to upload the files again.
Needed to extract a file from a tar file. No problem:
tar cvf filename.tar somefile
Just reinstalled SunOS4, restored local files from backup, and was cleaning up, removing the restored files from their temporary location when I typed rm -rf /usr and wondered why it was taking so long... I got to do it all over again.
When trying to clean my home folder of temp/backup files:
Run this:
rm -rf *~
# OOPS! DON'T RUN THESE:
rm -rf * # OOPS! Deleted all files in $PWD
rm -rf ~ # OOPS! Deleted all files in $HOME
rm -rf ~* # OOPS! Deleted all users' home folders!!!
I've done a rm -rf * .o but the best I've seen is:
userdel -r root
It was done by a novice though and he was learning.
Intending to clean up the build directory, I removed all the source code for a project with:
rm * .o
Since then, first thing in my projects is a clean target in the Makefile
Removed my whole home directory when trying to clean a floppy disk with the command:
rm -rf * /mnt/floppy
The worst I've seen:
In /var/www// Instead of removing the folder with [rm -r var]
He removed the complete /var folder with [rm -r /var] One slash can do a lot :/
So yeh, that guy had fun trying to get backups... what only made it worse because shutting down the server and doing a recovery would just get everything back upto the last little update, the backups were only done once a week
I was doing a log parse for a mail server using grep, so I typed:
grep -r event_string /var/log > output
Unfortunately, I was in /var/log when I typed it, so every time it matched the string it wrote the string to a file that it was in the directory it was checking...When it got to that file, the file became a space devouring beast that could not be fed. Filled up the whole machine, and, since it was a mail server, caused a pretty pressing problem.
net send /domain "Hello World"
Oh sh!+, this isn't the lab domain.....
A lot of people have mentioned rm -rf. I'd like to point out that it isn't the trickiest command. The one you really have to worry about is sudo rm -rf. After deleting my entire Python site-packages directory, I now refer to that command as the "nuclear option".
rm -vfr /*
Which I now do: rm -vfr ./*
I'll start with the standard disclaimer: It was many years ago, I had just started, I was a noob, honest!
I was trying to debug something on a Cisco router (don't even remember what it was), but I just couldn't figure out what exactly I needed. If you've ever tried the debug command in IOS, you'll know what I mean. Every command has a ton of subcommands, arguments, options, etc.
Finally, I came up with a brilliant idea! I'll just "debug all" and then strip out the useless stuff. (I can hear the groans from the other people who've tried this).
Long story short: it killed the router. It just happened to be the core router for the ISP I was working for. 30,000 people suddenly had no internet access.
Yes, it was dumb. Yes, the ISP should not have been letting newbies run around on core routers unsupervised. Yes, we should have had hot standby. Etc, etc. :)
I had my home directory mounted into a chroot in loop mode to do some work. The chroot was taking too much space, so I had to remove it, and I just did
rm -rf /path/to/the/chroot
It too a bit longer than I thought before I realized it was removing the documents from my loop-mounted homedir altogether...
Anyone else read this and thought "damn, I done most of those"?
How about "alias rm rm -i" in your bashrc for root? then you can't as easily zap everything?
Also keep a backup script in ~ for the production db at work, so easy to run, I always do it before I log in with write privs, and if i am just running a bespoke report, use a ro user!
