Adding desktop shortcuts in Ubuntu 18.04

I like having my desktop filled with shortcuts to programs that I regularly use. In Ubuntu 18.04, there is a lack of a “right click > add shortcut to desktop” option. If you are missing this option too, don’t fret! There is another way to do just that.

In the Terminal, navigate to:


If you list all files with ls, you will see many different .desktop files each of which houses the information for executing a program. It also tells the UI where to find the icon that it should display.

Find the program that you wish to add to the desktop (you should find it here if it is installed through apt and it is a GUI application)

Copy the .desktop file to your own Desktop folder:

cp /usr/share/applications/<app>.desktop /home/<user_name>/Desktop/<app>.desktop

Next we need to make the desktop file executable:

chmod +x /home/<user_name>/Desktop/<app>.desktop

Now looking at the desktop, you should see your copied .desktop file.

ubuntu 18.04 desktop shortcut
ubuntu 18.04 desktop shortcut

Double clicking on the file will bring up a prompt, warning that the program is untrusted. Click “Trust and Launch”

ubuntu desktop 18.04 launch application
Ubuntu 18.04 desktop launch application

Once accepted, the application should launch as normal. Close it down, and you should now see the once .desktop file changed into an icon launcher as intended!

ubuntu 18.04 desktop shortcut 2
ubuntu 18.04 desktop shortcut

Coloured SSH terminal – Ubuntu host

If you SSH into a remote Ubuntu terminal and do not see coloured text, here might be a solution. The problem is on the remote host, where bash is missing the profile and configuration for coloured commands. I will help fix this.

Connect via SSH to the remote host. You need to look for 2 hidden files in the user’s home directory.

  1. .bashrc
  2. .profile

You can check by issuing:

ls -la

If you do not see the aforementioned files, this might be an easy fix.

You should already have a default copy of .bashrc and .profile in a directory called /etc/skel/.

Simply issue these commands to copy them into your user’s home directory:

cp /etc/skel/.bashrc ~/
cp /etc/skel/.profile ~/

Now test this by logging out of your user/SSH and connecting again. Hopefully now you should have a colourful terminal!

Ubuntu : Desktop Shortcuts

If you have ever wondered how to add desktop shortcuts to Ubuntu, fret no more!

Whenever I use Ubuntu, it is normally through command line. But recently, I have been using Ubuntu 16.04 Desktop in a VirtualBox container, almost solely as a C IDE. I’ve never really understood the workings of the GUI (properly) and have almost become used to finding it unnecessary, until now.

Unfortunately, adding icons to the desktop is a little more involved then just “right click, make shortcut” as you would in Windows, but it’s not too complicated.

In Windows, an icon is usually a direct link to an .exe file within the installation directory.
In Linux, it’s a script. It’s a file that tells the GUI environment the icon picture, the text to be displayed underneath the icon, and can house different configurations such as the name depending on local language settings for example.

To add an icon, you need to locate the folder where all of your installed software icons are stored.

Icons folder

Continue reading “Ubuntu : Desktop Shortcuts”

f2b-nuke | a fail2ban shell script

You will find the project on GitHub: f2b-nuke – GitHub

f2b-nuke is a gnu/linux shell script designed to easily and efficiently manipulate any given fail2ban jail, en masse. It is a fully interactive, CLI tool built to fulfill 2 tasks:

  • unbanning the contents of an entire jail whilst creating a backup list of all items
  • New: banning (or re-banning) an entire list of IPs to the specified jail.

As the use of fail2ban slowly diminishes, this script can be viewed as complete. I will continue to maintain the project through Github.


  • Misconfiguration/testing
  • Configuration/testing
  • Persistent bans might cause long shutdown/reboot times on limited resourced systems
  • As part of a maintenance routine

Slow Ubuntu Server Restarts – SOLVED

Good Friday! I’m in a pretty good mood today; not only because it is Friday, but because I have figured out what is causing the server to reboot R-E-A-L-L-Y SLOOOOOOOWLY.

So.. according to alot of old posts scattered across the internet, most people had issues upon boot that “Starting System V RunLevel Compatibility” be be the error if the system can’t load the correct display adapter drivers on a GUI edition of linux.
My issue was “Stopping System V RunLevel Compatibility”  message being shown at reboot or shutdown for 5-10 minutes. No error logs, no other messages… nothing!
I suspected it to be maybe a kernel upgrade issue as the aforementioned posts suggested; but it couldn’t be related… could it? My issue was the wrong side of boot and I need not to worry about GUI issues since I use CMD.

So it must be another issue…

…. I told myself. The past week of trying to fix this issue must not be in vein!
I had a revelation; since there aren’t any errors, it must be doing something! It must be executing stop commands to gracefully shut down.

It MUST be a service.

On booting the local copy; everything works as it should. It runs through without a hitch. Logging into tty1; everything must be loaded by now. By complete chance, I found the culprit first time around. fail2ban.
Issued the fail2ban stop command and there I was….. waiting for 5 minutes for the service to come to a complete halt. Excited that I may have solved the problem; a reboot that took 30 seconds, confirmed it.

What is happening?

Ok, so I may have already noticed some stuff. After a reboot, CPU% is around 35% @ fail2ban process. I’m not using ubuntu’s packaged application, it’s a newer stable release. But this new release also features persistent banning over reboots. A quick search confirmed that fail2ban does indeed re-ban the IP’s from the persistent database, but only one at a time.
This MUST be happening also, on shutdown (instead of just flushing iptable entries) Hence the time spent removing the IP’s from iptables, one by one.

Upon knowing this information (and realizing that there’s just under 3000 f2b banned entries), I’m going to review the way fail2ban is setup, keeping in mind that more then 3000 entries will probably be the death of the reboot as we know it.
I have also semi-automated the process of unbanning the entries in fail2ban; the guide can be found here.

Maybe my troubles can help someone else out…. who knows!