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:
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.
You can check by issuing:
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!
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.
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!