Tomcat: Redirect default home page to another URL

To create a redirect from default page in Tomcat edit CATALINA_HOME/webapps/ROOT/index.html:
nano /CATALINA_HOME/webapps/ROOT/index.html

Where CATALINA_HOME is your tomcat directory. Delete the content and replace with the following:

<meta http-equiv="refresh" content="0;URL=<url>">


and replace <url> with new destination.

Debian: ssh authentication key instead of password – RSA key pairs

Why ssh authentication instead of using regular password?

Well, a few reasons, but the most important ones (for me) are 1. secure management of many servers without many passwords 2. password-less logon to transfer data securely over encrypted ssh tunnels (backup and disaster recovery). However, there is a big risk: if anyone got a hold of your RSA key they can easily logon and control your server, especially if you have no passphrase to enhance security. It’s very important to keep your keys safe (we’ll get to that later).

You can probably find hundreds of different versions of how-to’s, but I believe this is the easiest way to do this on Debian. If you’re familiar with your distro you can simply modify this to fit your needs.

Log on to the client machine as user who’d be accessing servers (not root I hope), then:

Generate the key pair: ssh-keygen
Hit enter to use default directory to save the key.
Passphrase (optional). To use ssh auth without entering password simply hit enter, otherwise enter a pass phrase. It’s always a good practice to pick something impossible to guess, like a short line of favorite song!
Your key will be created and stored in ~/.ssh directory and key fingerprint or image will be shown.

Now from the same machine install the key on your server(s), and from user’s home directory:
ssh-copy-id -i .ssh/ username@serverip or FQDN
You will be asked to enter remote servers’ password to log on. Key will be added to the server and confirmation message will be displayed:

Now try logging into the machine, with “ssh ‘username@serverip'”, and check in:
to make sure we haven’t added extra keys that you weren’t expecting.

You may also add the key manually on the server for any user who’d be accessing the server.

That’s it! You can logon to remote server through ssh: ssh username@serverip. If you had entered a pass phrase then you will only need to enter that, and if not you’ll be let right in. Anything that’d be using ssh for communication should be authenticated successfully without password (if you don’t have a pass phrase), like scp, rsync, etc 🙂

We’re done! If you need to change your pass phrase for any reason:
ssh-keygen -p
… and don’t forget to tighten security so your keys can’t be viewed by unauthorized users:
chmod go-w ~/
chmod 700 ~/.ssh
chmod go-rwx ~/.ssh/*

Now you can do anything you want, like running rsync to sync a folder with an external source:
rsync -auvz -e ssh remoteuser@remotehost:/remote/dir /local/dir/

Linux: Cannot move folders – inter-device move failed, unable to remove target: Is a directory

This is somewhat simple as long as we understand the concept. mv or move does not actually move the file/folder to another location within the same device, it merely replaces the pointer in the first sector of your device. The pointer (in inode table) will be moved, but nothing is actually being copied. This will work as long as you stay within the same media/device.

Now, when you try to move files from one device to another (/dev/sda1 to /dev/sdb1) you will run into “inter-device move failed, unable to remove target: Is a directory” error. This happens when mv has to actually move your data to another device, but cannot remove the inode/pointer, because if it did then there will be no data to fall back to, and if it didn’t then mv operation is not really complete because we will end up with data in source. Damned if you do and damned if you don’t, so it’s wise not to do it to begin with!

In such situation cp is best. Copy your data over and then remove your source manually.