Sunday, November 1, 2015

Gridcoin Headless Wallet on Ubuntu (VPS)

I got into Gridcoin [1] at about the start of 2015 if I remember correctly, a cryptocurrency based on BOINC [2]. Users are no longer doing "useless" hashing work, but rather contribute to space, medical or other useful science topics by donating computing power. Now, with the help of Gridcoin, contributors can get a "payment" for their work on white-listed projects.

Since the Gridcoin Project uses both Proof of Work (technically "Proof of Research", aka PoR) and Proof of Stake schemes at the same time, it is beneficial to have a node running to stake coins and earn interest on them.  

  • How to install gridcoinresearchd (compiling & .deb)
  • Automatically unlock wallet for staking
  • Wallet upgrade (automatic & manual)

Getting a VPS Server

I bought a server with the features listed below for about 20 €/year (don't remember exactly as I bought a cheaper package first and then upgraded) from time4VPS (affiliate link). I can say I am satisfied with their service. They have great support, astonishing prices, upgrading servers work seamlessly and really easy setup. Perfect uptime so far and low ping within the EU, even my small mumble server has a ping around 80 ms.
  • 2.4 GHz CPU core
  • 1024 MB RAM (+ 512 MB of fixed SWAP)
  • 40 GB HDD
  • 400 Mbit/s port connection (dedicated)
  • 1 TB monthly traffic

Installing Gridcoin-Research

This will be a guide on how to install gridcoinresearchd, that is the gridcoin-research daemon. This is a headless version of the client, that is there will be no GUI for configuration or inspection. However, this is not even needed if you just want to run a client and know that it works. Three ways of installing I have covered here are,
  1. Pull from git and compile
  2. Use pre-compiled .deb packages for Ubuntu
  3. Add PPA to your system (simplest)

Compile from git repository

Installing the client is well-described on the Github page and on the official site of the project [3] [1] and following it step-by-step will result in a perfect installation. I copied here the important commands relevant for installing it on an Ubuntu VPS.
  1. sudo apt-get install ntp git build-essential libssl-dev libdb-dev libdb++-dev libboost-all-dev libqrencode-dev
  2. git clone
  3. cd ~/Gridcoin-Research/src
  4. chmod 755 leveldb/build_detect_platform 
  5. make -f makefile.unix USE_UPNP=- 
  6. strip gridcoinresearchd
    sudo install -m 755 gridcoinresearchd /usr/bin/gridcoinresearchd
After this the daemon can be run from the terminal with the command,

Pre-compiled packages

Turns out that the compiler keeps getting out of RAM during the process and fails. So instead of compiling it on my own, I have decided (for now) to download pre-compiled .deb packages from launchpad. The latest compiled package can be downloaded from :

Select the one that matches your distribution and architecture and grab the link. Then on your server e.g.,

This will save into gridcoinresearchd_3.5.2.1-r166~ubuntu14.04.1_amd64.deb. Now I had a problem here with the "~" in the name, so what I usually do is replace it with a "-" to avoid issues when installing directly with dpkg.
mv gridcoinresearchd_3.5.2.1-r166~ubuntu14.04.1_amd64.deb gridcoinresearchd_3.5.2.1-r166-ubuntu14.04.1_amd64.deb
And lastly,
sudo dpkg -i gridcoinresearchd_3.5.2.1-r166-ubuntu14.04.1_amd64.deb
After this the daemon can be run from the terminal with the command,

Adding PPA to your system

Just recently I found that I can also install the Gridcoin daemon via PPA. From This is probably less fancy than compiling from the source, but definitely faster.
Code to add Gridcoin PPA to your system
sudo add-apt-repository ppa:gridcoin/gridcoin-daily
sudo apt-get update
sudo apt-get install gridcoinresearchd 

After this the daemon can be run from the terminal with the command,
And the next time you run
sudo apt-get update
sudo apt-get upgrade
to update your system, gridcoinresearchd will also be automatically upgraded.

Note: If you got a VPS from Time4VPS you first have to run sudo apt-get install software-properties-common python-software-properties before you can add-apt-repository.

Unlocking the Wallet for Staking

In order to stake coins - receive interest on the coins in your wallet - the wallet must be unlocked [9]. Of course, this only applies if your wallet is encrypted, which it should be (!) if you are storing it on a remote server! For obvious reasons.

The problem is, in order to unlock it, you have to type the password in your ssh session. This is secure. Unless someone gets access to your VPS server when he/she can check the terminal history (history) and your password is out. The solution is to use the autounlock feature in the config and provide an encrypted password. This will automatically unlock your wallet upon start.

Go to your desktop wallet and in the debug console do the following
execute encrypt YourwalletPassword
and add a last line to your gridcoinresearch.conf file

So you are essentially using an encrypted password that your client can decrypt and prove that it is indeed the correct password and so unlocks your wallet for staking. Pretty cool, huh? So even if someone has access to your VPS, they won't have your wallet passphrase.

Note: The password hashing algorithm takes a salt from the computer's CPU and hard drive. This means that the hash has to be generated on the machine where the wallet will run and as such the hash will be unique to that machine. (The same passphrase will result in different hashes on different computers!)

Config file

I have stripped down my config file and currently use only a minimal version. To edit your gridcoinresearch.conf file,
nano ~/.GridcoinResearch/gridcoinresearch.conf
The following lines need to be present,
rpcuser=whatever_you_want_you_dont_have_to_remember_it    rpcpassword=whatever_you_want_you_dont_have_to_remember_it
After this you should be able to run gridcoinresearchd and get some connections soon. Maybe not right away, but check back in 10-30-60 minutes and see if it works.

Note: The rpcuser and rpcpassword fields are necessary for the headless (gridcoin-researchd) client, you will get an error if these are not present. The "addnode" entries should be purely optional, peers should be found even without these entries.

Tip: "gridcoinresearchd" is a system command now and can be called quickly by starting to type it "grid..." and pressing [TAB]. Also, type gridcoinresearchd help to get a list of available commands with the headless client.

Keeping Gridcoin Updated

Upgrading for self-compiled client

I have written a scrip for myself to upgrade the client, based on the Github Linux guide [3] again. The script upgrades the client if it is installed in the "default" location (that is where I have installed it) in ~/Gridcoin-Reserach/. The script can then be added to the aliases file and simply run with a command. I personally like having a ~/MyScripts directory on my systems where I have a collection of scripts doing a range of things. I call this one ~/MyScripts/ and has the following in it.
#Script to Upgrade Gridcoin-Research client
#Install directory

###Config END###

#Defining some colours for message output

#Stop gridcoinresearch if running
gridcoinresearchd stop
#Go to the install Directory
cd $Dir
#Git update
echo "${red}Pulling Changes from Git Repository...${NC}"
sudo git fetch --all
sudo git reset --hard origin/master
echo "${red}Git Repository Updated!${NC}"
cd $Dir/src
chmod 755 leveldb/build_detect_platform
echo "${red}Making makefile.unix! This may take a while!${NC}"
make -f makefile.unix USE_UPNP=-
echo "${red}Makefile ready.${NC}"
strip gridcoinresearchd
sudo install -m 755 gridcoinresearchd /usr/bin/gridcoinresearchd
echo "${red}Upgrade finished. You can start Gridcoin-Research now\nby running 'gridcoinresearchd' ${NC}"
#Uncomment the following line to automatically run gridcoinresearchd upon finishing the client update

After copying this into the file remember to make the file executable with,
sudo chmod +X ~/MyScripts/
Then we can add an alias to call this script for the simple command grcupgrade. This file doesn't exist by default, so it will be likely empty if you haven't added commands to it before.
sudo nano ~/.bash_aliases
And add the following line to the file,
alias grcupgrade='sudo sh ~/MyScripts/'
Save with Ctrl+O and exit with, Ctrl+X. Then run the following command (or reboot if you wish) to apply changes made to the aliases file.
source ~/.bashrc
After this the upgrade script can be run by simply issuing the 
command. If you want gridcoinresearchd to start at the end of the client upgrade then you can uncomment the last line in the bash script. A further step is that you can run a cronjob to run this script, say once every week to make sure that your client gets upgraded.

Upgrading when installed via PPA

If you have added the gridcoin-daily PPA to your system, then as mentioned earlier, your gridcoin client will be upgraded the next time you do
sudo apt-get update
sudo apt-get upgrade


Resource usage

From personal experience I can say that running on 512 MB of system RAM is not going to work. I had multiple wallet crashes due to "out of memory" error. Therefore I would recommend a minimum of 1 GB for simply running the client (not compiling!). I think CPU power for running a simple wallet is not that much important, it mainly influences the time it takes to make the wallet from the git source. Even a Raspberry Pi's CPU can handle it.

If one wants to compile the client from the git repository as mentioned above, I would suggest having at least 2 GB of system RAM. Although, I cannot confirm if this would truly be enough. I personally am pulling the deb packages and installing it with dpkg for the moment.

Compiler error

Even though it should be simple to compile, I ran into a problem. The compiler ran for a while and then gave back a weird-looking error:
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
 Turns out this happens when it runs out of RAM. Command dmesg returned
[241411.374594] Out of memory in UB 8727: OOM killed process 11475 (cc1plus) score 0 vm:734444kB, rss:493656kB, swap:207248kB
I started investigating the use of a larger swap file [8], however for obvious reasons, the server restricts this (otherwise anyone could get e.g. 4 GB extra RAM for free). So I tried shutting down unnecessary services, apache, my mumble server and I even tried increasing swappiness. This was also set to 1, and cannot be changed. Again, because of server configuration and the virtualization.

Further help

gridcoinresearchd help
And of course, feel free to leave a comment if you find this useful or you got stuck somewhere.


Some extras briefly mentioned that are actually required, but beyond the scope of the article.

Automatic updates (cronjob)

Setting up a cronjob for the updater script is a good idea. Here is an example on how to set it to run once a week. Cron takes the following syntax,

Minute Hour Day_of_Month Month Day_of_Week Command
47 6 * * Sun grcupgrade
For example the above code would run the upgrade script every Sunday at 06:47.

Encrypt your wallet.dat

If you have a local Gridcoin wallet on your machine and would like to use the same on a VPS, you should encrypt it. This can be done through the GUI in Settings/Encrypt Wallet. Make sure to use a sufficiently strong password.

Copy an existing wallet.dat file to the server

If you have encrypted your wallet.dat file as mentioned above, it should be safe to copy it to a remote VPS server. This can be done securely with scp,
scp ~/GridcoinResearch/wallet.dat user@vps.server:/home/user/GridcoinResearch/
user: your username on the VPS server
vps.server: IP address or domain name of your VPS server


Tuesday, June 30, 2015

Internal Server Error on ownCloud Ubuntu Server 14.04

I have followed the automatic installation tutorial for ownCloud,[1] from,[2]. Needless to say, it didn't go as smooth as apt-get install and enjoy. After installing, enabling SSL with a self-signed certificate and using the absolute default settings I was greeted with a not so nice message below.
Internal server error message when trying to access


After quite a bit of searching the solution was to add he following lines to the config file /etc/apache2/apache2.conf,[3].
<Directory /var/www/>
   Options Indexes FollowSymLinks
   AllowOverride All
   Require all granted
Simple edit the file by
sudo nano /etc/apache2/apache2.conf
and add the mentioned lines to the end of the file.

Save changes with CTRL+O, exit with CTRL+X. Then restart apache2 with
sudo service apache2 restart
Or in case you are running Ubuntu 12.04
sudo /etc/init.d/apache2 restart
Your error should be fixed and ownCloud ready to be used.


[1] -
[2] -
[3] -

Saturday, June 27, 2015

Install & Configure Mumble Server (Murmur) on Ubuntu

"Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming. It can be compared to programs like Ventrilo or TeamSpeak. People tend to simplify things, so when they talk about Mumble they either talk about "Mumble" the client application or about "Mumble & Murmur" the whole voice chat application suite." [1]

Recently my Raspberry Pi broke down at home that was serving a small Mumble server (this is called Murmur). Since I am away from home I cannot fix it so I have decided to buy a VPS sever and run it off from there. I have found an amazing VPS provider that sells VPS plans starting from 9.99€/year with decent configuration (Affiliate link). This guide is for all those who want to easily set up and configure a server "ready to go" as fast as possible.


Installing Murmur (mumble server) is straightforward in Ubuntu, it can be done via the pat repository through apt-get commands.
Update your repository and packages that might be out of date
sudo apt-get update
sudo apt-get upgrade
Install and do an initial configuration on mumble-server
sudo apt-get install mumble-server
sudo dpkg-reconfigure mumble-server
The images below show what you will be prompted when running the dpkg-reconfigure command.
Select yes if you want mumble-server to start upon boot. This is a useful feature just in case the server or your OS crashes and otherwise you would forget to start your services.
Generally set this to "yes" as well to increase performance and audio quality of your server.
Finally, set a SuperUser password. This will be only used for logging in with the root account called "SuperUser" and administering channel properties.

The mumble server is now up and running, however it is not fully configured. Next is to set server password, audio quality, port and so on. Proceed to the next step.

Configure your Server

Mumble server has a single configuration file for interest for us located in /etc/mumble-server.ini. This file has to be edited with any kind of text editor of your liking.The configuration file is self-explanatory and there is also a complete documentation on it [2].
sudo nano /etc/mumble-server.ini
There are many settings here that you can tweak, however the  most important ones (for a quick setup at least) are the following.


This is the welcome message that will be displayed to clients when joining the server. The mumble client shows this message in the standard message window on the left side of the client.
welcometext="your welcome message comes here"
You can use standard html syntaxin the message to display something more than a plain text. Some examples:
<b>bold</b> - makes enclosed text bold
<i>italic</i>  - makes enclosed text italic
<br /> - inserts a line break


The port where users have to connect to the server. If you change the default port, make sure to let your users know.


Quite obviously, this is the server password users need to connect. Set it to something strong as the client is able to remember it, so users will not be promoted to enter this on every connection.


This is the audio bandwidth per user. The default is 70'000 bits/s and the higher you set this, the better the audio quality. Setting it higher to 130'000 has no effect, I usually go with 128'000 bits/s.


Defines the maximum number of users allowed on the server. If you are running a small server for a handful of people, this probably isn't so important for you, although setting it to 20-50 wouldn't hurt anyway. It becomes important when you are running a larger server and your bandwidth is limited.

Apply Changes

In order for the changes to take effect you have to restart the mumble server
sudo service mumble-server restart
There are of course a lot more settings, but these initial points are probably the most important. Feel free to play around.

Managing Channels

Once everything has been set up on the server side it is time to log in with a client and start configuring the channels. For starters, there will only be 1 root channel on the server.By default only the SuperUser (the mumble servers "root" user) has the right to add, delete and edit channels. So it is useful to give your account (the one you will personally use on your server) administrator rights. This saves the hassle of logging in all the time with the root account. To do this, follow these steps, which are also nicely explained in the wiki [3].

  1. Open a mumble client, navigate to Configure/Settings and check the "Advanced" checkbox at the bottom left corner.
    Configure/Settings window after enabling Advanced view by checking the checkbox at the bottom left corner of the window.
  2. Pick a username and connect to your server at the server's IP address, with the specified port and server password. 
  3. Click on Self/Register, which will lock your username on the server.
  4. Disconnect from the server.
  5. Reconnect to the server, however use the following username & password,
    password:<the one you set in dpkg-reconfigure mumble-server>

    In case you forgot the SuperUser password, don't worry. Log in to your server and re-run sudo dpkg-reconfigure mumble-server

    At this point you should be logged in as SuperUser and you have the right to create and edit channels. Simply right-click a channel and see what options you have.
  6. To give administrator rights to your user account select the root channel, right-click and select Edit.
  7. Go to the Groups tab and select admin from the dropdown menu. Then at the bottom of the window type your username into the field and click Add. See the image below.
    Root>Edit>Group window showing my user account added to the admin group. Afterwards, I can edit channels with my everyday user account.  
  8. Save changes by clicking OK. Now you can simply log out and log back in with you user account.
Editing channels is simply done by right-click/edit. You can also add new channel and sub-channels by selecting Add from the menu. Configure a server and channel structure of your liking!

But wait! There's more!

If you want to learn more about channel settings, groups and administration I strongly suggest watching the video below (10 minutes and you learn a lot). Groups and permissions are nicely explained and you can configure your server pretty good if you follow what is shown in the video.

If you have any questions, leave a comment below and I'll get back to you as soon as possible.


[1] -
[2] -
[3] -

Friday, June 26, 2015

Installing nodejs from Source

I needed to install a software using nodejs. Unlucky for me from the apt repository I could only get nodejs version 6.something, however the latest one is 12.5 asof this moment. Hence I decided to go ahead and build it for myself from source.

The steps were the usual required for compiling any software in general.

tar -xzvf node-v0.12.5.tar.gz
cd node-v0.12.5
sudo make install

However, after installing it I had no npm, which should be part of and installed along with nodejs. Seemed like node was not in my PATH so this had to be adjusted quickly.

The solution was to add /usr/local/bin/node to my PATH in ~/.profile
nano ~/.profile

And add either a new line like this:

or if you altready have a PATH defined, add this to the end

Press CTRL+O to write the file and CTRL+X to close nano. Finally,
source ~/.profile

npm worked just fine after this.

Wednesday, June 10, 2015

Repair Filesystem Errors in Ubuntu with fsck

I have an ATA 80GB HDD in my laptop now, which is, well yes, old and has some issues. I wanted to test it with fsck and tell it to repair any file system errors. So I looked into the topic a bit.

Important about fsck

The most important thing you need to know about fsck is that it can only fix filesystems if they are not mounted. Hence when your computer is running, you can (if you really want to) run fsck on your /home directory, however not on root. So in general there are 2 main approaches that you can implement to check your entire hard drive,
  1. Run a live CD version
  2. Run fsck during boot
Here I will only explain how to run fsck on boot as I think this is much less of a hassle than creating a live CD, booting from it etc. Furthermore, the benefit of running fsck at boot (as you will see) is that you can schedule it at intervals of your liking. Sort of a "set it and forget it" approach.

Let fsck attempt to fix errors automatically

Firstly tell fsck to automatically repair filesystem inconsistencies during boot. This can be set in the following steps. First, open /etc/default/rcS with a text editor, e.g. nano
sudo nano /etc/default/rcS 
 And find the line at the end where it says,
# automatically repair filesystems with inconsistencies during boot
and change the tunable "no" to "Yes".

Schedule fsck run interval on boot

Scheduling an fsck check can be based on 2 main parameters, invoked by 2 command parameters,
  • -c = sets interval based on how many times the filesystem was mounted
  • -i  = sets interval based on how much time has passed since the last check
The next step is to schedule fsck running in specific intervals. I have set mine for every 10 days initially, however later on I moved it to once per month to save some time at boot. Of course, next to this a mount-dependent check can be scheduled too.

Determine filesystem mount points

First of all, quickly check on which filesystem your root and home directory are mounted. I like to do this quickly and easily with
df -h
Example output of df -h command, showing mount points of different directories
From this you can see that my root directory is on /dev/sda2, while my /home is on /dev/sda3, hence I will tell fsck to check these filesystems.

Schedule fsck based on time interval

To tell fsck to check my root filesystem I have to issue the following command,
sudo tune2fs -i 1m /dev/sda2

Which will then return,
Information returned when executing above command.
This tells Ubuntu to run filesystem check at boot every month on the root directory. You can also use different intervals, below are some examples.
-i 10d = interval of 10 days
-i 1m = interval of 1 month
-i 2w = interval of 2 weeks

Schedule fsck based on number of mounts

Additionally, or instead of, time-based fileysystem checks you can also tell fsck to run after, say every filesystem 30 mounts. To do this use the -c parameter,
sudo tune2fs -c 30 /dev/sda2
Tip: If you wish to set any other interval, check out man tune2fs for more information!


Also, you can check if the effects really took place with,
sudo tune2fs -l /dev/sda2
This will give an output similar to the one below. The lines we are interested in are towards the bottom, highlighted in red.
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          9f344424-1e1c-47db-a2b6-13104e5c754c
Filesystem magic number:  0xEE12
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1120112
Block count:              4461312
Reserved block count:     223065
Free blocks:              1219061
Free inodes:              467223
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      893
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
RAID stride:              32603
Flex block group size:    16
Filesystem created:       Wed Oct 26 15:27:33 2011
Last mount time:          Wed Jun 10 08:06:25 2015
Last write time:          Wed Jun 10 09:53:37 2015
Mount count:              16
Maximum mount count:      27
Last checked:             Fri May 29 20:57:05 2015
Check interval:           2592000 (1 month)
Next check after:         Sun Jun 28 20:57:05 2015

Lifetime writes:          357 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       48
Default directory hash:   half_md4
Directory Hash Seed:      8dc55d5d-db7c-4717-ab06-6fad98d89896
Journal backup:           inode blocks
After this you are done, the above output will tell you when the previous and next checks were and will be. However, if you wish to run a one-off check at boot, you can do it as well.

Turning off periodic fsck check on boot

 Quoting from the tune2fs manual,
"It  is  strongly  recommended that either -c (mount-count-dependent) or -i (time-dependent) checking be enabled to force  periodic  full  e2fsck(8) checking of the filesystem.  Failure to do so may lead to filesystem corruption (due to bad disks,  cables, memory, or kernel bugs) going unnoticed, ultimately resulting in data loss or corruption."
However, if you really want to switch it off completely,
sudo tune2fs -c -1 -i 0
Which will turn off both time and max-mount-count dependent  checks.

Force check on next boot

If you want to do a check on the next boot execute the following command,
sudo touch /forcefsck
This will create a temporary file in / that tells fsck to execute a filesystem check on the next boot.

Monday, May 18, 2015

Tweak Terminal Appearance in XFCE4 Ubuntu

I have spent some time recently to fine-tune the looks of my Ubuntu machine in XFCE4. I have slightly modified my conky, created a customized desktop background, started tweaking things under the hood and I have also given some time and thought to the terminal.

The terminal with full black background looks like my computer came from the 90's, so I wanted to give it a fresher, more modern look. I wanted to do the following:
  • Add a transparent background that shows the contents behind the window. This is useful if e.g. I am searching for something on the web and have to issue some commands at the same time. I can see through the window and work faster.
  • Give the window some lighter colours
  • Remove window frame
It is pretty easy to set up these things, everything can be done from within the menus in the terminal. Simply go to  Edit/Preferences and set it the way you want it to look.

Window Management Tweaks

A little trouble came when setting up the transparent background. Namely, it wouldn't show the contents directly behind the window, but rather a greyed out section of the desktop background. This became annoying almost immediately.

The solution was to go to Settings/Settings Manager/Window Management Tweaks/
Settings menu in Xfce4 - Look at Window Manager Tweaks
And tick the checkbox for Enable display compositing.
Window Manager Tweaks menu - check the first tickbox on the top left
After this the terminal window should be transparent, as much as set in the terminal settings menu. Also, if you want to make it look even cooler, you can set it to be more transparent while moving! This applies to all windows on your machine and it not only looks nice, but allows you to roughly see what you will cover with the window. It is actually useful.

Terminal Settings

You wouldn't believe who much cooler it looks like if you take out this option. And don't worry about the closing/minimizing of the window, you can get used to it pretty easily.
  • Close: Ctrl + Shift + Q
  • Maximize: F11

Remove Borders

To disable border on new terminal windows go to Terminal/Edit/Preferences/Appearance
Adjusting temrinal appearance
And uncheck the Display borders around new windows.

Make the Terminal Transparent

This is where you can change the actual transparency of the terminal only. From the "appearance" tab (see above) select Transparent Background in the Background options and adjust the slider to your liking. I am using 80% as this allows me to clearly see the text in the terminal window as well as roughly see the contents behind the window.

This is especially useful when I have to look up references on the internet and copy commands form the browser. I can simply go full screen with the terminal and still see the commands in my browser that I have to type. It also gives a smoother look to the whole thing and doesn't feel so monotone.

Close the terminal and restart it. VoilĂ ! Let me know what you think and if you have some cool customizations on your UI please share it!

Monday, May 11, 2015

How to Install .ttf Fonts "Manually"


I just had  a .ttf font I wanted to install to use in conky, but by double-clicking and executing it, the installer (font-viewer) failed. I received the error message "Install Failed". No clue why this has happened as I have previously installed fonts this way.
"Install Failed" message when trying to install a ttf font
"Install Failed" message when trying to install font

I knew about gnome-font-viewer that I could get from the Software Centre, but I didn't feel like installing another software just to get a new font. There has to be another way.


The solution, turned out, was quite simple. Copy the .ttf file to ~/.fonts/ and you are good to go. No logout or restart is needed, nothing.

So from the terminal,

cp /route/to/font.ttf ~/.fonts/

After this when starting a document editing software, e.g. AbiWord, the new fonts will be available.

Wednesday, February 11, 2015

How to Change Login Background in Ubuntu 12.04

Changing the desktop background is easy and probably everyone has already done it. What about tweaking your machine even further to your liking? What about changing the background of the LOGIN screen? Let's do it!

By default, Ubuntu 12.04 uses the following file as its login background,

To change this  default background what one can do is to do a backup of this original image and copy your background here with the same name. Probably not the most elegant solution, but it serves its purpose.
  1. Make a backup of the original image
    sudo mv /usr/share/backgrounds/warty-final-ubuntu.png /usr/share/backgrounds/warty-final-ubuntu_backup.png
  2. Copy the image you want to use as background
    sudo cp ~/MyBackground.png /usr/share/backgrounds/warty-final-ubuntu.png
    Where "MyBackground.png" is the image you want to set as login background. Use absolute paths for copying, that is /home/user/......
  3. Reboot or relog to your your system to be welcome by the new login background.

If you wish to undo the changes or simply use another background picture for the login screen, simply copy back either the original image or the new one you like.

  • The background of your selection must be a *.png file, matching screen size.
  • The name has to be warty-final-ubuntu.png

Saturday, February 7, 2015

Generate Random Passwords Easily

I have added a short function in my ~/.bashrc file that allows me to quickly generate a password of any length containing letters, numbers and symbols. This comes in handy when registering for a new website or similar.



The command uses /dev/urandom to generate the random string. Evaluating the true randomness and strength of this password is beyond this guide. However, this should be sufficient for any general use.

Step by Step

  1. Edit the .bashrc file to add a new function that can then be called by an alias command.
    nano ~/.bashrc
  2. Add the following lines to the end of the file [1],
    tr -dc "a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?=" < /dev/urandom | fold -w $1 | head -n 4
  3. Then add an alias to easily call this function by,
    nano ~/.bash_aliases
  4. Add an alias of your liking.
    alias genpasswd='passwdgen' 
  5. Apply changes by either logging out and back in or,
    sudo source ~/.bashrc

Originally I wanted to call the alias command "passwdgen", however when using TAB to quickly substitute commands this was conflicting with "passwd". Hence I decided to use "genpasswd".

Done. The command can be used as,
genpasswd <password_length>
For example I want a password with 30 characters I would do,

:~$ genpasswd 30

Note: You get 4 passwords as an output from the function (head -n 4). This is simply to give a choice for the user to decide which password to use. Also, this adds another increment of randomness.

The list of used symbols can be altered by editing the function contents within the quotes "a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?=". Adding extra symbols will increase the strength of the password, however some website (rarely) have restrictions on what symbols can be used.