Stories of foolishness?

I just locked myself out of su on my headless server using pw usermod USER -G operator. I tried plugging in a monitor, but it's not getting a signal. I should have had a second terminal open as root so I could fix it. Now I have to reboot and hope the graphics card still works. I know the root password, so it shouldn't be a problem to get back in, but is there any way to resolve this without rebooting?

Also, what foolish things have you done on FreeBSD, and how would you mitigate that risk in the future?
 
From the Windows world of remote desktops I observed the practice of people installing big fat warning wallpapers on production servers to keep them from doing the stupid, like shutting the box down. All shells on UNIX look essentially the same, as I learned in the late 1990's when I did a hard shutdown on the wrong physical box with no remote hands and no car available. I lost a day of traveling to/from the colo by public transportation. I was a student back then. I learned things that day. That was when I changed the appearance of my shell prompt on production environments versus test environments. Fortunately working as root in any capacity on a production environment has become the exception.
 
Connecting a monitor will be the best option. Other option is to reboot and try to login blindly using root and then add your user back to wheel group.
 
Reboot the server instead of the local machine. I did one time in 2001, then I've got the OCD to check out the hostname before doing that. :D
 
rm * ~ to remove the backups.
This was before version control for the part of the tree, so I had to rewrite the complete code in there from scratch.
 
rm * ~ to remove the backups.
But you removed the backups, why you complain?!

BTW, I think, I also use from time to time rm *~, although I know I should not, and I think also did once your error.
Now I tend to use X11 copy and paste to put the files to erase, or use shell completion and complete.
 
rm * ~ to remove the backups.
This was before version control for the part of the tree, so I had to rewrite the complete code in there from scratch.
The closer I've got from this was like writing a couple of scripts, delete the wrong directory (with the scripts I wrote inside by a couple of hours), tried to recover from backup and realize that I did a backup before starting...
 
I recently wrote a shell script which should remove a bin directory in a custom path
Bash:
rm -rf ${custompath}/bin

Problem was that ${custompath} was set to an empty string by accident. I ran the script as root and removed the complete /bin directory of the server.
 
Consolidate my NAS with the build server / former workstation, thus moved the storage drives in there, but forgot to change the fstab entries for swap. Then went on to rebuild stuff like chromium and libreoffice. Took me an hour or so realize it uses a few gigabytes from a total of 2TB (sic!) of swap - then I knew something was wrong...

Luckily only one of the mirror drives was overwritten, but I had an uneasy time until the scrub was finished healing.
Using gpt labels now.
 
First mistake, not realizing good old MS-DOS counts primary partitions first, then extended partitions. Had to add a drive to a customer's system. Partitioned it, then proceeded to format E:, that should have been D:, formatted the customer's data partition :'‑(

Showed a colleague some instructions from a README, selected the text in PuTTY and accidentally clicked the right mouse button, that pasted all the commands to the command line; including a shutdown -r now. Booted a few hundred network engineers off the server. :'‑(

Rebuilding my server (full reinstall) and forgetting to backup an encryption key for an external 2TB drive :rolleyes:

Doing rm -rf * thinking I was in /usr/ports but was actually in /usr :rolleyes:

I've been working in IT for 30 years now, made lots of stupid mistakes.
 
I just changed the SSD in a valuable laptop 2 days ago. It turned on in the middle of surgery and then never again.

I used to let the battery drain before working on open laptops. Guess I had a point there.
 
I was using a mirrored pool that combines a nvme ssd and a 2.5" hdd since then im using nvme ssd alone in stripe mode. I was cleared labels of ZFS partitions using zpool labelclear without even thinking...
 
There was a period (I don't know why) I repeatedly wrote the file on which I wanted to work on with the syntax
command <file> </path/to/directory/containing/the/file>
instead of
command </path/to/the/file>
easy to understand where this led, right? ;)

One day, I wanted to delete everything in my usb pendrive, mounted under /mnt, so I did (while being in my $HOME):
rm -r * /mnt
I wondered why the process were taking so much to finish and why the activity led of my HD was blinking so rapidly and for so much time, to discover with a ls -l later what exactely happened... :eek:
 
tcsh(1) has an interesting option.

Code:
       rmstar (+)
               If set, the user is prompted before `rm *' is executed.
Won't help much if you blindly enter "Y" of course. It should make you stop and think. I simply stopped using rm * and always include a directory (relative or absolute) i.e. rm -rf ports/* or rm -rf /usr/ports/*. Still a bit weary to use in scripts; rm -rf ${SOMEDIR}/* is dangerous if $SOMEDIR doesn't contain what you expect, or is empty :eek:
 
dd to the wrong device, which comprised a single ZFS pool with:
  • a non-encrypted file system
  • an encrypted file system where I kept nearly all my virtual hard disks for VirtualBox.
I stopped soon after realising my mistake. IIRC only two of the virtual disks were wrecked.
 
Back
Top