The Linux Experiment

In my last post, I discussed several Docker containers that I’m using for my home media streaming solution. Since then, Plex Media Server has updated to 0.9.11.4 for non-Plex Pass users, and there’s another update if you happen to pay for a subscription. As the Docker container I used (timhaak/plex) was version 0.9.11.1 at the time, I figured I’d take the opportunity to describe how to

• update Docker itself to the latest version
• run a shell inside the container as another process, to review configuration and run commands directly
• update Plex to the latest version, and describe how not to do this
• perform leet hax: commit the container to your local system, manually update the package, and re-commit and run Plex

Updating Docker

I alluded to the latest version of Docker having features that make it easier to troubleshoot inside containers. Switching to the latest version was pretty simple: following the instructions to add the Docker repository to my system, then running

sudo apt-get update
sudo apt-get install lxc-docker

upgraded Docker to version 1.3.1 without any trouble or need to manually uninstall the previous Ubuntu package.

Run a shell using docker exec

Let’s take a look inside the plex container. Using the following command will start a bash process so that we can review the filesystem on the container:

docker exec -t -i plex /bin/bash

You will be dropped into a root prompt inside the plex container. Check out the filesystem: there will be a /config and a /data directory pointing to “real” filesystem locations. You can also use ps aux to review the running processes, or even netstat -anp to see active connections and their associated programs. To exit the shell, use Ctrl+C – but the container will still be running when you use docker ps -a from the host system.

Updating Plex in-place: My failed attempt

Different Docker containers will have different methods of performing software updates. In this case, looking at the Dockerfile for timhaak/plex, we see that a separate repository was added for the Plex package – so we should be able to confirm that the latest version is available. This also means that if you destroy your existing container, pull the latest image, then launch a new copy, the latest version of Plex will be installed (generally good practice.)

But wait – the upstream repository at http://shell.ninthgate.se/packages/debian/pool/main/p/plexmediaserver/ does contain the latest .deb packages for Plex, so can’t we just run an apt-get update && apt-get upgrade?

Well, not exactly. If you do this, the initial process used to run Plex Media Server inside the Docker container (start.sh) gets terminated, and Docker takes down the entire plex container when the initial process terminates. Worse, if you then decide to re-launch things with docker start plex, the new version is incompletely installed (dpkg partial configuration).

So the moral of the story: if you’re trying this at home, the easiest way to upgrade is to recreate your Plex container with the following commands:

docker stop plex

docker rm plex

# The 'pull' process may take a while - it depends on the original repository and any dependencies in the Dockerfile. In this case it has to pull the new version of Plex.
docker pull timhaak/plex

# Customize this command with your config and data directories.
docker run -d -h plex --name="plex" -v /etc/docker/plex:/config -v /mnt/nas:/data -p 32400:32400 timhaak/plex

Once the container is up and running, access http://yourserver:32400/web/ to confirm that Plex Media Server is running. You can check the version number by clicking the gear icon next to your server in the left navigation panel, then selecting Settings.

Hacking the container: commit it and manually update Plex from upstream

If you’re more interested in hacking the current setup, there’s a way to commit your existing Plex image, manually perform the upgrade, and restart the container.

First, make sure the plex container is running (docker start plex) and then commit the container to your local filesystem (replacing username with your preferred username):

docker commit plex username/plex:latest

Then we can stop the container, and start a new instance where bash is the first process:

docker stop plex

docker rm plex

# Replace username with the username you selected above.
docker run -t -i --name="plex" -h plex username/plex:latest /bin/bash

Once inside the new plex container, let’s grab the latest Plex Media Server package and force installation:

curl -O https://downloads.plex.tv/plex-media-server/0.9.11.4.739-a4e710f/plexmediaserver_0.9.11.4.739-a4e710f_amd64.deb

dpkg -i plexmediaserver_0.9.11.4.739-a4e710f_amd64.deb

# When prompted, select Y to install the package maintainer's versions of files. In my instance, this updated the init script as well as the upstream repository.

Now, we can re-commit the image with the new Plex package. Hit Ctrl+D to exit the bash process, then run:

docker commit plex username/plex:latest

docker rm plex

# Customize this command with your config and data directories.
docker run -d -h plex --name="plex" -v /etc/docker/plex:/config -v /mnt/nas:/data -p 32400:32400 username/plex /start.sh

# Commit the image again so it will run start.sh if ever relaunched:
docker commit plex username/plex:latest

You’ll also need to adjust your /etc/init/plex.conf upstart script to point to username/plex.

The downside of this method is now that you’ve forked the original Plex image locally and will have to do this again for updates. But hey, wasn’t playing around with Docker interesting?

I recently took it upon myself to rebuild a general-purpose home server – installing a new Intel 530 240GB solid-state drive to replace a “spinning rust” drive, and installing a fresh copy of Ubuntu 14.04 now that 14.04.1 has released and there is much less complaining online.

The “new hotness” that I’d like to discuss has been the use of Docker to containerize various processes. Docker gets a lot of press these days, but the way I see it is a way to ensure that your special snowflake applications and services don’t get the opportunity to conflict with one another. In my setup, I have four containers running:

• Plex Media Server, using the docker-plex configuration from Tim Haak
• SABnzbd+, also using a Dockerfile from Tim Haak (docker-sabnzbd)
• Sonarr – formerly known as NZBDrone, and a Mono/.NET competitor to Sickbeard, which I also like – with tuxeh/sonarr
• CouchPotato with setup from needo

I like the following things about Docker:

• Since it’s new, there are a lot of repositories and configuration instructions online for reference.
• I can make sure that applications like Sonarr/NZBDrone get the right version of Mono that won’t conflict with my base system.
• As a network administrator, I can ensure that only the necessary ports for a service get forwarded outside the container.
• If an application state gets messed up, it won’t impact the rest of the system as much – I can destroy and recreate the individual container by itself.

There are some drawbacks though:

• Because a lot of the images and Dockerfiles out there are community-based, there are some that don’t follow best practices or fall out of an update cycle.
• Software updates can become trickier if the application is unable to upgrade itself in-place; you may have to pull a new Dockerfile and hope that your existing configuration works with a new image.
• From a security standpoint, it’s best to verify exactly what an image or Dockerfile does before running it – for example, that it pulls content from official repositories (the docker-plex configuration is guilty of using a third-party repo, for example.)

To get started, on Ubuntu 14.04 you can install a stable version of Docker following these instructions, although the latest version has some additional features like docker exec that make “getting inside” containers to troubleshoot much easier. I was able to get all these containers running properly with the current stable version (1.0.1~dfsg1-0ubuntu1~ubuntu0.14.04.1). Once Docker is installed, you can grab each of the containers above with a combination of docker search and docker pull, then list the downloaded containers with docker images.

There are some quirks to remember. On the first run, you’ll need to docker run most of these containers and provide a hostname, box name, ports to forward and shared directories (known as volumes). On all subsequent runs, you can just use docker start $container_name – but I’ll describe a cheap and easy way of turning that command into an upstart service later. I generally save the start commands as shell scripts in /usr/local/bin/docker-start/*.sh so that I can reference them or adjust them later. The start commands I’ve used look like:

Plex
docker run -d -h plex --name="plex" -v /etc/docker/plex:/config -v /mnt/nas:/data -p 32400:32400 timhaak/plex
SABnzbd+
docker run -d -h sabnzbd --name="sabnzbd" -v /etc/docker/sabnzbd:/config -v /mnt/nas:/data -p 8080:8080 -p 9090:9090 timhaak/sabnzbd
Sonarr
docker run -d -h sonarr --name="sonarr" -v /etc/docker/sonarr:/config -v /mnt/nas:/data -p 8989:8989 tuxeh/sonarr
CouchPotato
docker run -d -h couchpotato --name="couchpotato" -e EDGE=1 -v /etc/docker/couchpotato:/config -v /mnt/nas:/data -v /etc/localtime:/etc/localtime:ro -p 5050:5050 needo/couchpotato
These applications have a “/config” and a “/data” shared volume defined. /data points to “/mnt/nas”, which is a CIFS share to a network attached storage appliance mounted on the host. /config points to a directory structure I created for each application on the host in /etc/docker/$container_name. I generally apply “chmod 777″ permissions to each configuration directory until I find out what user ID the container is writing as, then lock it down from there.

For each initial start command, I choose to run the service as a daemon with -d. I also set a hostname with the “-h” parameter, as well as a friendly container name with “–name”; otherwise Docker likes to reference containers with wild adjectives combined with scientists, like “drunk_heisenberg”.

Each of these containers generally has a set of instructions to get up and running, whether it be on Github, the developer’s own site or the Docker Hub. Some, like SABnzbd+, just require that you go to http://yourserverip:8080/ and complete the setup wizard. Plex required an additional set of configuration steps described at the original repository:

• Once Plex starts up on port 32400, access http://yourserverip:32400/web/ and confirm that the interface loads.
• Switch back to your host machine, and find the place where the /config directory was mounted (in the example above, it’s /etc/docker/plex). Enter the Library/Application Support/Plex Media Server directory and edit the Preferences.xml file. In the <Preferences> tag, add the following attribute: allowedNetworks=”192.168.1.0/255.255.255.0″ where the IP address range matches that of your home network. In my case, the entire file looked like:
  

  <?xml version="1.0" encoding="utf-8"?>
  <Preferences MachineIdentifier="(guid)" ProcessedMachineIdentifier="(another_guid)" allowedNetworks="192.168.1.0/255.255.255.0" />

• Run docker stop plex && docker start plex to restart the container, then load http://yourserverip:32400/web/ again. You should be prompted to accept the EULA and can now add library locations to the server.

Sonarr needed to be updated (from the NZBDrone branding) as well. From the GitHub README, you can enable in-container upgrades:

[C]onfigure Sonarr to use the update script in /etc/service/sonarr/update.sh. This is configured under Settings > (show advanced) > General > Updates > change Mechanism to Script.

To automatically ensure these containers start on reboot, you can either use restart policies (Docker 1.2+) or write an upstart script to start and stop the appropriate container. I’ve modified the example from the Docker website slightly to stop the container as well:

description "SABnzbd Docker container"
author "Jake"
start on filesystem and started docker
stop on runlevel [!2345]
respawn
script
/usr/bin/docker start -a sabnzbd
end script
pre-stop exec /usr/bin/docker stop sabnzbd

Copy this script to /etc/init/sabnzbd.conf; you can then copy it to plex, couchpotato, and sonarr.conf and change the name of the container and title in each. You can then test it by rebooting your system and running “docker ps -a” to ensure that all containers come up cleanly, or running “docker stop $container; service $container start”. If you run into trouble, the upstart logs are in /var/log/upstart/$container_name.conf.

Hopefully this introduction to a media server with Docker containers was thought-provoking; I hope to have further updates down the line for other applications, best practices and how this setup continues to operate in its lifetime.

Recently the Kitchener Waterloo Linux Users Group held a couple of presentations on setting up your own personally hosted cloud. With their permission we are pleased to also present it below:

If the video above does not work here is the MP4 version. Archive link.

It’s been a while but once again here is the latest instalment of the series of posts where I install the major, full desktop, distributions into a limited hardware machine and report on how they perform. Once again, and like before, I’ve decided to re-run my previous tests this time using the following distributions:

• Debian 7.6 (GNOME)
• Elementary OS 0.2 (Luna)
• Fedora 20 (GNOME)
• Kubuntu 14.04 (KDE)
• Linux Mint 17 (Cinnamon)
• Linux Mint 17 (MATE)
• Mageia 4.1 (GNOME)
• Mageia 4.1 (KDE)
• OpenSUSE 13.1 (GNOME)
• OpenSUSE 13.1 (KDE)
• Ubuntu 14.04 (Unity)
• Xubuntu 14.04 (Xfce)

I also attempted to try and install Fedora 20 (KDE) but it just wouldn’t go.

All of the tests were done within VirtualBox on ‘machines’ with the following specifications:

• Total RAM: 512MB
• Hard drive: 8GB
• CPU type: x86 with PAE/NX
• Graphics: 3D Acceleration enabled

The tests were all done using VirtualBox 4.3.12, and I did not install VirtualBox tools (although some distributions may have shipped with them). I also left the screen resolution at the default (whatever the distribution chose) and accepted the installation defaults. All tests were run between October 6th, 2014 and October 13th, 2014 so your results may not be identical.

Results

Just as before I have compiled a series of bar graphs to show you how each installation stacks up against one another. Measurements were taken using the free -m command for memory and the df -h command for disk usage.

Like before I have provided the results file as a download so you can see exactly what the numbers were or create your own custom comparisons (see below for link).

Things to know before looking at the graphs

First off if your distribution of choice didn’t appear in the list above its probably not reasonably possible to be installed (i.e. I don’t have hours to compile Gentoo) or I didn’t feel it was mainstream enough (pretty much anything with LXDE). As always feel free to run your own tests and link them in the comments for everyone to see.

First boot memory (RAM) usage

This test was measured on the first startup after finishing a fresh install.

All Data Points

RAM

Buffers/Cache

RAM – Buffers/Cache

Swap Usage

RAM – Buffers/Cache + Swap

Memory (RAM) usage after updates

This test was performed after all updates were installed and a reboot was performed.

All Data Points

RAM

Buffers/Cache

RAM – Buffers/Cache

Swap Usage

RAM – Buffers/Cache + Swap

Memory (RAM) usage change after updates

The net growth or decline in RAM usage after applying all of the updates.

All Data Points

RAM

Buffers/Cache

RAM – Buffers/Cache

Swap Usage

RAM – Buffers/Cache + Swap

Install size after updates

The hard drive space used by the distribution after applying all of the updates.

Install Size

Conclusion

Once again I will leave the conclusions to you. Source data provided below.

Source Data

• The Spreadsheet (Legacy Version)
• Zip file of images for “Big distributions, little RAM 7″

This assumes you want to set a static IP address on the network device eth0.

Open up the interfaces file

sudo nano /etc/network/interfaces

and remove or comment out the line that says

iface eth0 inet dhcp

then add the following lines in its place:

iface eth0 inet static
address [static IP address, i.e. 192.168.1.123]
netmask [i.e. 255.255.255.0]
network [i.e. 192.168.1.0]
broadcast [i.e. 192.168.1.255]
gateway [i.e. 192.168.1.1]
dns-nameservers [i.e. 8.8.8.8]

Save the file and reboot the server. On some systems you may also need to update /etc/resolv.conf and /etc/hosts

The initial version of CoreGTK, version 2.24.0, has been tagged for release today.

Features include:

• Targets GTK+ 2.24
• Support for GtkBuilder
• Can be used on Linux, Mac and Windows

CoreGTK is an Objective-C language binding for the GTK+ widget toolkit. Like other “core” Objective-C libraries, CoreGTK is designed to be a thin wrapper. CoreGTK is free software, licensed under the GNU LGPL.

You can find more information about the project here and the release itself here.

This post originally appeared on my personal website here.

A big part of my move from Windows to Linux has been finding replacements for the applications that I had previously used day-to-day that are not available on Linux. For the major applications like my web browser (Firefox), e-mail client (Thunderbird), password manager (KeePass2) this hasn’t been a problem because they are all available on Linux as well. Heck you can even install Microsoft Office with the latest version of wine if you wanted to.

Unfortunately there still remains some programs that will simply not run under Linux. Thankfully this isn’t a huge deal because Linux has plenty of alternative applications that fill in all of the gaps – the trick is just finding the one that is right for you.

Mp3tag is an excellent Windows application that lets you edit the meta data (i.e. artist, album, track, etc.) inside of an MP3, OGG or similar file.

Mp3tag on Windows

As a Linux alternative to this excellent program I’ve found a very similar application called EasyTAG that offers at least all of the features that I used to use in Mp3tag (and possibly even more).

EasyTAG on Linux

For anyone looking for a good meta data editor I would highly recommend trying this one out.

With the recent questions surrounding the security of TrueCrypt there has been a big push to move away from that program and switch to alternatives. One such alternative, on Linux anyway, is the Linux Unified Key Setup (or LUKS) which allows you to encrypt disk volumes. This guide will show you how to create encrypted file volumes, just like you could using TrueCrypt.

The Differences

There are a number of major differences between TrueCrypt and LUKS that you may want to be aware of:

• TrueCrypt supported the concept of hidden volumes, LUKS does not.
• TrueCrypt allowed you to encrypt a volume in-place, without losing data, LUKS does not.
• TrueCrypt supports cipher cascades where the data is encrypted using multiple different algorithms just in case one of them is broken at some point in the future. As I understand it this is being talked about for the LUKS 2.0 spec but is currently not a feature.

If you are familiar with the terminology in TrueCrypt you can think of LUKS as offering both full disk encryption and standard file containers.

How to create an encrypted LUKS file container

The following steps borrow heavily from a previous post so you should go read that if you want more details on some of the commands below. Also note that while LUKS offers a lot of options in terms of cipher/digest/key size/etc, this guide will try to keep it simple and just use the defaults.

Step 1: Create a file to house your encrypted volume

The easiest way is to run the following commands which will create the file and then fill it with random noise:

# fallocate -l <size> <file to create>
# dd if=/dev/urandom of=<file to create> bs=1M count=<size>

For example let’s say you wanted a 500MiB file container called MySecrets.img, just run this command:

# fallocate -l 500M MySecrets.img
# dd if=/dev/urandom of=MySecrets.img bs=1M count=500

Here is a handy script that you can use to slightly automate this process:

#!/bin/bash
NUM_ARGS=$#

if [ $NUM_ARGS -ne 2 ] ; then
    echo Wrong number of arguments.
    echo Usage: [size in MiB] [file to create]

else

    SIZE=$1
    FILE=$2

    echo Creating $FILE with a size of ${SIZE}MB

    # create file
    fallocate -l ${SIZE}M $FILE

    #randomize file contents
    dd if=/dev/urandom of=$FILE bs=1M count=$SIZE

fi

Just save the above script to a file, say “create-randomized-file-volume.sh”, mark it as executable and run it like this:

# ./create-randomized-file-volume.sh 500 MySecrets.img

Step 2: Format the file using LUKS + ext4

There are ways to do this in the terminal but for the purpose of this guide I’ll be showing how to do it all within gnome-disk-utility. From the menu in Disks, select Disks -> Attach Disk Image and browse to your newly created file (i.e. MySecrets.img).

Don’t forget to uncheck the box!

Be sure to uncheck “Set up read-only loop device”. If you leave this checked you won’t be able to format or write anything to the volume. Select the file and click Attach.

This will attach the file, as if it were a real hard drive, to your computer:

Next we need to format the volume. Press the little button with two gears right below the attached volume and click Format. Make sure you do this for the correct ‘drive’ so that you don’t accidentally format your real hard drive!

Please use a better password

From this popup you can select the filesystem type and even name the drive. In the image above the settings will format the drive to LUKS and then create an ext4 filesystem within the encrypted LUKS one. Click Format, confirm the action and you’re done. Disks will format the file and even auto-mount it for you. You can now copy files to your mounted virtual drive. When you’re done simply eject the drive like normal or (with the LUKS partition highlighted) press the lock button in Disks. To use that same volume again in the future just re-attach the disk image using the steps above, enter your password to unlock the encrypted partition and you’re all set.

But I don’t even trust TrueCrypt enough to unlock my already encrypted files!

If you’re just using TrueCrypt to open an existing file container so that you can copy your files out of there and into your newly created LUKS container I think you’ll be OK. That said there is a way for you to still use your existing TrueCrypt file containers without actually using the TrueCrypt application.

First install an application called tc-play. This program works with the TrueCrypt format but doesn’t share any of its code. To install it simply run:

# sudo apt-get install tcplay

Next we need to mount your existing TrueCrypt file container. For the sake of this example we’ll assume your file container is called TOPSECRET.tc.

We need to use a loop device but before doing that we need to first find a free one. Running the following command

# sudo losetup -f

should return the first free loop device. For example it may print out

/dev/loop0

Next you want to associate the loop device with your TrueCrypt file container. You can do this by running the following command (sub in your loop device if it differs from mine):

# sudo losetup /dev/loop0 TOPSECRET.tc

Now that our loop device is associated we need to actually unlock the TrueCrypt container:

# sudo tcplay -m TOPSECRET.tc -d /dev/loop0

Finally we need to mount the unlocked TrueCrypt container to a directory so we can actually use it. Let’s say you wanted to mount the TrueCrypt container to a folder in the current directory called SecretStuff:

# sudo mount -o nosuid,uid=1000,gid=100 /dev/mapper/TOPSECRET.tc SecretStuff/

Note that you should swap your own uid and gid in the above command if they aren’t 1000 and 100 respectively. You should now be able to view your TrueCrypt files in your SecretStuff directory. For completeness sake here is how you unmount and re-lock the same TrueCrypt file container when you are done:

# sudo umount SecretStuff/
# sudo dmsetup remove TOPSECRET.tc
# sudo losetup -d /dev/loop0

This post originally appeared on my personal website here.

If you are not familiar with the concept of virtual hard drive volumes, sometimes called file containers, they are basically regular looking files that can be used by your computer as if they were real hard drives. So for example you could have a file called MyDrive.img on your computer and with a few quick actions it would appear as though you had just plugged in an external USB stick or hard drive into your computer. It acts just like a normal, physical, drive but whenever you copy anything to that location the copied files are actually being written to the MyDrive.img file behind the scenes. This is not unlike the dmg files you would find on a Mac or even something akin to TrueCrypt file containers.

Why would I want this?

There are a number of reasons why you may be interested in creating virtual volumes. From adding additional swap space to your computer (i.e. something similar to a page file on Windows without needing to create a new hard drive partition) to creating portable virtual disk drives to back up files to, or even just doing it because this is Linux and it’s kind of a neat thing to do.

What are the steps to creating a file container?

The process seems a bit strange but it’s actually really straight forward.

1. Create a new file to hold the virtual drive volume
   (Optional) Initialize it by filling it with data
2. Format the volume
3. Mount the volume and use it

Create a new file to hold the virtual drive volume

There are probably a million different ways to do this but I think the most simple way is to run the following command from a terminal:

fallocate -l <size> <file to create>

So let’s say you wanted to create a virtual volume in a file called MyDrive.img in the current directory with a size of 500MiB. You would simply run the following command:

fallocate -l 500M MyDrive.img

You may notice that this command finishes almost instantly. That’s because while the system created a 500MiB file it didn’t actually write 500MiB worth of data to the file.

This is where the optional step of ‘initializing’ the file comes into play. To be clear you do not need to do this step at all but it can be good practice if you want to clean out the contents of the allocated space. For instance if you wanted to prevent someone from easily noticing when you write data to that file you may pre-fill the space with random data to make it more difficult to see or you may simply want to zero out that part of the hard drive first.

Anyway if you choose to pre-fill the file with data the easiest method is to use the dd command. PLEASE BE CAREFUL – dd is often nicknamed disk destroyer because it will happily overwrite any data you tell it to, including the stuff you wanted to keep if you make a mistake typing the command!

To fill the file with all zeros simply run this command:

dd if=/dev/zero of=<your file> bs=1M count=<your file size in MiB>

So for the above file you would run:

dd if=/dev/zero of=MyDrive.img bs=1M count=500

If you want to fill it with random data instead just swap /dev/zero for /dev/urandom or /dev/random in the command:

dd if=/dev/urandom of=MyDrive.img bs=1M count=500

Format and mount the virtual volume

Next up we need to give the volume a filesystem. You can either do this via the command line or using a graphical tool. I’ll show you an example of both.

From the terminal you would run the appropriate mkfs command on the file. As an example this will format the file above using the ext3 filesystem:

mkfs -t ext3 MyDrive.img

You may get a warning that looks like this

MyDrive.img is not a block special device.
Proceed anyway? (y,n)

Simply type the letter ‘y’ and press Enter. With any luck you’ll see a bunch of text telling you exactly what happened and you now have a file that is formatted with ext3!

If you would rather do things the graphical way you could use a tool like Disks (gnome-disk-utility) to format the file.

From the menu in Disks, select Disks -> Attach Disk Image and browse to your newly created file (i.e. MyDrive.img).

Don’t forget to uncheck the box!

Be sure to uncheck “Set up read-only loop device”. If you leave this checked you won’t be able to format or write anything to the volume. Select the file and click Attach.

This will attach the file, as if it were a real hard drive, to your computer:

Next we need to format the volume. Press the little button with two gears right below the attached volume and click Format. Make sure you do this for the correct ‘drive’ so that you don’t accidentally format your real hard drive!

Make sure you’re formatting the correct drive!

From this popup you can select the filesystem type and even name the drive. You may also use the “Erase” option to write zeros to the file if you wanted to do it here instead of via the terminal as shown previously. In the image above the settings will format the drive using the ext4 filesystem. Click Format, confirm the action and you’re done. Disks will format the file and even auto-mount it for you. You can now copy files to your mounted virtual drive. When you’re done simply eject the drive like normal or press the square Stop button in Disks. To use that same volume again in the future just re-attach the disk image using the steps above.

To mount the formatted file from the terminal you will need to first create a folder to mount it to. Let’s say we wanted to mount it to the folder /media/MyDrive. First create the folder there:

sudo mkdir /media/MyDrive

Next mount the file to the folder:

sudo mount -t auto -o loop MyDrive.img /media/MyDrive/

Now you can copy files to the drive just like before. When you’re finished unmount the volume by running this command:

sudo umount /media/MyDrive/

And there you have it. Now you know how to create virtual volume files that you can use for just about anything and easily move from computer to computer.

This post originally appeared on my personal website here.

If you’ve used KeePass on Windows you may be very attached to its auto-type feature, where with a single key-combo press the application with magically type your user name and password into the website or application you’re trying to use. This is super handy and something that is sadly missing by default on Linux. Thankfully its also very easy to make work on Linux.

1. Start by installing the xdotool package

On Debian/Ubuntu/etc simply run:

sudo apt-get install xdotool

2. Next find out where the keepass2 executable is installed on your system

The easiest way to do this is to run:

which keepass2

On my system this returns /usr/bin/keepass2. This file is actually not the program itself but a script that bootstraps the program. So to find out where the real executable run:

cat /usr/bin/keepass2

On my system this returns

#!/bin/sh
exec /usr/bin/cli /usr/lib/keepass2/KeePass.exe "$@"

So the program itself is actually located at /usr/lib/keepass2/KeePass.exe.

3. Create a custom keyboard shortcut

The process for this will differ depending on which distribution you’re running but it’s usually under the Keyboard settings. For the command enter the following:

mono /usr/lib/keepass2/KeePass.exe --auto-type

Now whenever you key in your shortcut keyboard combo it will tell KeePass to auto-type your configured username/password/whatever you setup in KeePass. The only catch is that you must first open KeePass and unlock your database.