FIVE minutes to a safer Ubuntu experience for noobs AND pros.

in witness •  7 years ago  (edited)

If you've been around Linux for any amount of time you've accidentally permanently deleted a file (or worse) that you did not mean to.

If this has never happened to you, then you:

 1) Have not been around Linux that long.
 2) Have legendary concentration skills.
 3) Are lying!

-----------------------------------
tl;dr Five Second Version:

Problem:
Ubuntu deletes files without asking if it's OK to do so. This causes accidental file deletions and lots of unnecessary headaches!

Solution:

echo "# User specific aliases and functions" >>>> /root/.bashrc ; echo "alias rm='rm -i'" >> /root/.bashrc

 

Now try to delete a file from a new terminal session in a fresh terminal window. Problem solved!

NOTE: If you decide to run the one-liner above, please don't log out of your current SSH session - Test that you can establish a new SSH session before logging out of your primary terminal! 

If you have doubts about what the above one-liner does, and prefer to learn in a step-by-step, read the Five Minute Version below. P.S. Please vote for me as a WITNESS. Instructions for how to vote are at the bottom of this tutorial.

END tl;dr Five Second Version...
------------------------------------

The Five Minute Version:

If you didn't catch everything in the "tl;dr" version, then read on. You might learn something!

My goal is to arm Ubuntu users of all skill levels with an extra layer of protection that can help prevent accidental  and potentially catastrophic file loss. This might, just prevent a few heart attacks, and possibly save a few jobs along the way!

In my journey to create my first Steemit Witness server, I came across a fellow Steemian Witness who had accidentally deleted some files instead of copying them due to a typo. Yes indeed, the cp and rm key combinations are quite hard to just typo, thanks for pointing it out... but it happens!  Coming from a CentOS Linux background, I wondered how this was even possible even with a terrible case of dyslexia or major distraction. So I decided to test for myself:

1) root@chewbaca[/]# cd /usr/src
2) root@chewbaca[/usr/src]# touch foo.txt
3) root@chewbaca[/usr/src]# ll
-rw-r--r--  1 root root    0 Jan 18 01:33 foo.txt
4) root@chewbaca[/usr/src]# rm foo.txt
5) root@chewbaca[/usr/src]# ll
6) root@chewbaca[/usr/src]# 

 

What did I just do?

1) I changed into a directory which I knew was safe to play around in.../usr/src
2) I created an empty file in /usr/src called "foo.txt"
3) I listed the contents of /usr/src to see if my file creation was successful. (it was)
4) I tried to remove the file called foo.txt
5) I listed the contents of the /usr/src directory
6) /usr/src was empty, yuck!

For me, having bash setup this way sounds needlessly dangerous, only because I've seen myself and too many other people delete files in shells that they did not mean to, even when they had an extra added layer of protection in them. Running without this extra layer of protection sounds like a disaster waiting to happen. So what is that magical extra layer? I'm glad you asked!

Here is how the same scenario plays out on a CentOS machine:

root@chewbaca[/]# cd /usr/src
root@chewbaca[/usr/src]# touch foo.txt
root@chewbaca[/usr/src]# ll
-rw-r--r--  1 root root    0 Jan 18 01:33 foo.txt
root@chewbaca[/usr/src]# rm foo.txt
rm: remove regular empty file `foo.txt'? n
root@chewbaca[/usr/src]# ll
-rw-r--r--  1 root root    0 Jan 18 01:33 foo.txt
root@chewbaca[/]# 

 

If you notice, it asked me if I REALLY wanted to remove the file. And, you can see that I answered "No" when I hit the "n" key, then pressed  ENTER.  You can see from "ll" that the file remained safe and sound. 

So lets pretend I really wanted to get rid of the file...how would I do that?  If you guessed that the way to do it, is to type "y" and press  ENTER, then you are correct!

However, that can be cumbersome for data sets with huge numbers of files that you are absolutely sure you wish to delete, like a directory full of a thousand of files for example. Nobody wants to sit there and press the "y+ENTER" keys 1000 times in a row.  On the other hand, it can be a  good test before deleting huge data sets that you you've got your command right before blowing everything away into the ether. For example, you can try to delete a directory and all of it's contents with the command that you have crafted. Run your command and verify that the first few files that the system asks you to delete are indeed the ones you wanted to blast away. If you like what you see, then you can force delete everything without a prompt the same way Ubuntu does by default. To do that, simply run the following:

root@chewbaca[/]# rm -f foo.txt
root@chewbaca[/]# ll
root@chewbaca[/]#

 

(The above example is just removal of a singular file, I wont jump into directories in this post.)

By adding the -f argument (force) you've bypassed your new, super-duper-improved bash shell file removal protections. In essence from this day forward you are going to have to add the -f argument when you don't want to be prompted to confirm file deletion. It's a pretty small price to pay for the insurance involved!

So how do we set this up on an Ubuntu box? One simple line of code is all you need. We will assume you are logged in as the root user. If you want to do this for a particular user, then you will need to to locate that user's .bashrc file, usually in /home/user/.bashrc

But, for simplicity we're dealing with the root user in this example. Open the file called /root/.bashrc in your favorite text editor.

Then copy and paste this into the last line of the file:

# User specific aliases and functions
alias rm='rm -i'

 

Then save and close the file. 

IMPORTANT: As with anything that potentially alters the way SSH or the terminal works, make sure you can still login via SSH from a remote location using a second instance of PuTTY or whatever you use for  SSH, before closing the current shell. If you can't login, remove or fix the lines you just added to .bashrc from your primary SSH session, then try a secondary session again. 

Once logged into the secondary PuTTY instance, test the new behavior in the new shell session, and if you are satisfied, you can log out and put a smile on your face knowing that you've made your server a safer place.

=================================


If you liked this, please vote for me as a witness. Witness votes are different than regular votes.

A witness helps to power the Steem blockchain, which is one of the critical components which makes steemit.com work. Without witnesses, there is no Steem blockchain and no steemit.com. Witnesses contribute servers, bandwidth, electricity and technical support among other things, at their own expense. By voting for a witness, you help offset these costs.

Here's how to vote for me:
Just go to https://steemit.com/~witnesses. At the very bottom of the page you will see something like this: 

Simply type "glowhost-matt" into the box, and click the vote button.

----------------------------

This post is dedicated to @Drakos for all the help he offers the community and especially for getting me up in running in my humble beginnings.
 

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

There is an issue with the steemit editor and the one-liner above.

It should be >> and not >>>>

So your command line should be:
echo "# User specific aliases and functions" >> /root/.bashrc ; echo "alias rm='rm -i'" >> /root/.bashrc

For a safer experience, that five minutes would be better spent making a non-root user and locking down the root account.

Maybe, but that's for a different tutorial. If your SSH private keys are secure, users are a waste of time and keystrokes and add layers of complications to otherwise simple tasks, especially for servers maintained by a single person. If you are trying to save a server from crashing in a downward spiral, seconds count.

If your only authentication method is via private keys, with a passphrase, restricted to certain IP addresses, on a non-default port, you won't have a problem administrating your server as root.

This is infinitely more secure than allowing the world access to SSH, and then hoping that if(when) they get user access, they are too dumb to load malware from bash or snoop for vulns.

To extrapolate my point, your comment suggests that to be secure, you'd also need to shut down your steemit user login (root) to protect your SBD or SP (root's money), and then create a sub user (not currently possible), because that's the only way to be safe.

  ·  7 years ago (edited)

Upvoted for the good info here, but this is not direction I was going in.

Too many parts of the system are easy to mess up as root, doing work as an unprivileged user and escalating when necessary gives you time to think about what you are about to do.

Personally, I treat sudo like a loaded gun, and I make damn sure i know what it's pointed at when I pull the trigger.

When logged in as root every command becomes a loaded gun.

EDIT: Also in a tailspin there is sudo su to save you extra keystrokes, but emergencies are the exception not the rule.

Ahhhh! Yes I can agree with you there. I wasn't even thinking about the Linux desktop users that might come across this post. On the other hand, killing a few desktops, laptops and servers is how I learned the most valuable lessons early on.

I suppose I was lucky to have learned from the start how to run as root (didn't know there was another way). At some point, the training wheels have to come off I guess, at least for those looking to advance their Linux skills to the next level. (Run it as root!)

As you mentioned, it's still good to have a working handle-brake though, and that was the purpose of this post :)

I'm going to keep your point in mind for any future Linux articles I post. I'll need to consider to remember the day-to-day user and hobbyist more carefully.