Recently in HELP-CENTER Category

Virtualisation is one of the big next things to become mainstream technology. But it's a complex technology as there are many different software solutions available that differ greatly in terms of usability, flexibility and performance. As always there is a trade-off between ease-of-use and the performance of the guest system on your hardware. This time we will try to get a virtual machine up and running with a minimum of possible obstacles on our way to success, and we will try to install a cutting-edge Linux OS, Fedora-11-Preview, which will finally be released in about two weeks, today!

After all, trying out a new Linux distribution without the risk of making a mess of your hard disk is one of the most attractive features of virtualisation. What makes creating a guest virtual machine easy is the graphical user interface of VirtualBox from Sun Microsystems, that will guide us through the process in an intuitive way. Nevertheless the downside of this software is that even though it's open source, it's not entirely free. According to Sun's "VirtualBox Personal Use and Evaluation License (PUEL)" the software is free to use for personal and educational purposes as well as for product evaluation:

Sun grants you a personal, non-exclusive, non-transferable, limited license without fees to reproduce, install, execute, and use internally the Product a Host Computer for your Personal Use, Educational Use, or Evaluation. "Personal Use" requires that you use the Product on the same Host Computer where you installed it yourself and that no more than one client connect to that Host Computer at a time for the purpose of displaying Guest Computers remotely. "Educational use" is any use in an academic institution (schools, colleges and universities, by teachers and students). "Evaluation" means testing the Product for a reasonable period (that is, normally for a few weeks); after expiry of that term, you are no longer permitted to evaluate the Product.
But even though you'll need a commercial license from SUN to use VBox after evaluation, the download is free of charge and the PUEL allows for intense testing and is practicable for a number of non-commercial environments.

Getting VirtualBox for Your Linux Distribution

As we are going to install a new Fedora 11 as a guest on top of your current Linux system, the host, the first step is obviously to get VirtualBox for your host system and install it there. Fortunately SUN has prepared binaries for a number of different Linux distributions for download, so go to Sun's download page here and choose your package. Binaries are available in rpm or deb format, so your system's native installation tool should do the job. Just bear in mind to install the kernel headers and the gcc compiler first, to enable VirtualBox to compile a kernel module that will be loaded on boot after installation.

Unlike XEN which changes the way your usual Linux system works fundamentally, VirtualBox is just another application that runs inside your normal environment without changing anything on your host, except that it relies on the new kernel module created on installation.

Preparing VirtualBox for Installation of Fedora

Do you have two hours to burn? Let's get going.

To get to the point where we can start to install Fedora, we basically have to prepare a virtual disk and attach a boot medium to the virtual machine.


By now you will have found the VirtualBox GUI in the System Tools menu and have started to create a new virtual machine.

First, we have to give it a name and select the OS type.

Adjust the memory slider to at least 512 MB or even more if you can afford it. The more memory you assign to the virtual machine the faster it will run eventually.
   xvm1.gif

xvm2.gif    In a second step we need to create a virtual hard disk in a file. During installation of the guest system this file will be used as the device "/dev/sda". All formatting and partitioning is being performed inside this file although it seems to be a normal block device for the guest system to use.

Later, when Fedora uses its hard disk you will be asked to erase all your data on the device "/dev/sda". I can see the sweat on your face when you click the OK button for the first time. Your real hard disk, called /dev/sda as well, will survive this procedure, believe me.

You have to choose the final size of your filesystem for the Fedora installation here, so think twice how much space you will need.
As you can see I have only spent 4 Gigabytes for my Fedora test system, enough to finish a default installation. But your mileage may vary, you know, and it's not easy to expand your virtual disk after finishing the installation.
   xvm3.gif

xvm4.gif    Initialising the file that represents your virtual disk will take a while.

Check that the correct vdi-file is selected and finish this part of the job.


Before you can start the new virtual machine (to install Fedora) some minor changes to the default settings have to be made.

First of all I would recommend to change the network configuration.
   xvm5.gif

xvm6.gif    Usually the VirtualBox GUI selects NAT, but I think it's more straightforward to configure the network interface to share the physical host interface with the new guest system.


I don't know whether or not this is really necessary in your situation, but it does not hurt anyway.

As a last step we need to tell VirtualBox where to find the installation media.

If you have a download of the Fedora packages at hand stored in ISO format, you can use it here.

For the sake of simplicity I would like to go a different route and would ask you to download the 166 MB netinstall.iso file from the Fedora downloads page. This file could be burned to a CD making up for a nice boot CD, but we can use the downloaded iso-file here as the requested "Image File".

The only problem is, that we did not attach the file to the virtual machine yet.
   xvm7.gif

To make it available we have to go back to the "Virtual Media Manager" in the File menu and choose the downloaded iso-file as a CD/DVD image.
   xvm8.gif

I hope you have come this far and I'd like to encourage you to start your new virtual machine to go ahead with the installation. Once you've hit the start button again, you should be greeted with the Fedora installation window, and from this point onwards everything should work as if you had inserted a real CD and tried to install on bare hardware. In the course of installation you will inevitably reach the point where the hard disk has to be formatted, so keep an eye on the size of your install disk, it is exactly the size of your vdi-file. It does not matter that your real hard disk is also referenced by /dev/sda, your new /dev/sda is entirely separate, so dont't hesitate to repartition it to your hearts content. And you can safely install the GRUB boot loader in the master boot record, your original one will not be overwritten by the new installation. That's the magic of virtualisation.


After finishing your Fedora installation, there is one thing to remember, you have to remove the installation media before booting (the virtual machine) again. Well, you know how we had attached the iso-file to the machine, simply untick the box to detach it, then power off the virtual machine and start it again. Congratulations to your new Fedora 11 almost two weeks ahead of schedule.

How to secure your home

| 1 Comment | No TrackBacks
One of the many advantages of the Linux operating system is its separation of user data from system files. Traces of your daily use of the system will show up in your home directory located in the home folder alongside other user's playgrounds. Over time various assets will assemble inside your home directory, which are not equally important to you.

Things like your archived email messages, your financial records or outlines of your secret plans are mangled with the latest downloads of music or fresh software versions, all in one place. To secure your home you need to separate your core files (and configurations) from everything else that has been sourced from a public place like the internet and does not need protection.


What we need to do is to separate the sensitive data from everything else in your home directory and put it into a secure container that is left encrypted until access to the data inside is needed.

So this is our plan:

  • Setup an encrypted container with a filesystem to use.
  • Transfer all sensitive data to the container
  • Create links to the container in our home directory
  • Use our new tool with care
As you will expect the second step will be the most challenging, because we will easily miss some of our sensitive data to transfer to the container.

Don't worry about step one and three, I'll lend you a hand to perform these steps without much trouble.
img1.jpg
But why don't we simply transfer all of our home directory to the encrypted container?

This obvious solution is really not the best one. The security of our sensitive data relies on the fact that the container is encrypted almost all the time, when sensitive data is not used. If we'd put our home into the container we would not even be able to log in. Or we had to open up the container for the duration of our entire session, leaving the sensitive data unencrypted for a long time. This is clearly not what we want to protect our core files.

Preparing the safe

Let's go ahead and start preparing our encrypted container that will be a very big file holding all our valuable data. We have to decide where to store the big file (i.e /home/safe) and we need to make sure that whatever backup we make, this file is included. Issue the following commands as superuser (root):

dd if=/dev/urandom of=/home/safe bs=1M count=2000
LOOP=$(losetup -f)
/sbin/losetup $LOOP /home/safe
/sbin/cryptsetup create safe $LOOP
ls -l /dev/mapper

The first command is used to create the file and fill it with pseudo-random data. Feel free to adapt the amount of blocks that are being written to the file to suit your needs, count=2000 will create a 2 gigabyte file. The following commands find out a free loop device, attach our file to the device and finally create a new block device representing the decrypted bunch of data. Make sure that you use a good passphrase for the container.

By now you should have a device file called /dev/mapper/safe that can be treated just like any ordinary disk partition, ie /dev/sda1. So we can create a filesystem on this new device now and can mount it on the mountpoint /safe, which we create for this purpose.

mkfs -t ext3 -c /dev/mapper/safe
mkdir /safe
mount /dev/mapper/safe /safe


Our container is now mounted on the directory /safe and is ready to be filled up with our valuables.

Making life easier

But before we get to the tricky part of deciding which data shall be moved to the safe it's time to make using our safe a little easier. Usually you would not be logged in as the superuser (root) when you need to open up your encrypted safe. Let's set up two simple scripts that help you using the safe while working as a normal user on the system. Apart from knowing the passphrase to unlock the safe there is one more requirement to restore the unencrypted content of your safe. Creating device files and mounting them on directories is a job for root, not for ordinary users. As a consequence the two scripts must change their permissions to run as root, which can be achieved by adding the following two lines to the file /etc/sudoers:

joe ALL = NOPASSWD: /root/safeon
joe ALL = NOPASSWD: /root/safeoff


Joe is now permitted to run the two scripts as root, once he prefixed the script names with the sudo command:

sudo /root/safeon
sudo /root/safeoff


Make sure that the scripts are at their proper place in /root

/root/safeon

#!/bin/bash

LOOP=$(/sbin/losetup -f)
echo $LOOP > /home/joe/loopdevice
/sbin/losetup $LOOP /home/safe
/sbin/cryptsetup create safe $LOOP
mount /dev/mapper/safe /safe
ls -la /safe


/root/safeoff

#!/bin/bash

umount /dev/mapper/safe
LOOP=$(cat /home/joe/loopdevice)
/sbin/cryptsetup remove safe
/sbin/losetup -d $LOOP
rm /home/joe/loopdevice
ls -la /safe

Filling up the safe with valuables

Now that our safe is working well we don't have any excuses not to fill it with data that should be protected. If you know where your email software stores its archived messages move the folder to the safe completely and create a symbolic link to the new destination like this:

mkdir /safe/joe
chown joe /safe/joe
mv $HOME/mail /safe/joe
ln -s /safe/joe/mail $HOME/mail


What makes moving our valuables to the safe so tricky is that we do not exactly know where they are. Seriously, you can expect some of them in obvious places, but be aware that most software store their data in dot-directories like .evolution .ssh .gnupg and so on. So keep on searching. And enjoy your safe.


We have set-up this blog to provide you with information you need to get the most of open source software. Inevitably you'll run into some problems when using Linux and open source, so here are some of the answers to your problems.

Don't give up, we're here to help!

You can also request support using our website at http://kerry-linux.ie/support

Recent Comments

  • Easy Jobs: Terrific work! This is the type of information that should read more
  • Lorette Meek: I wanted to thank you for this great read!! I read more
  • Ralph: Actually, with Movable Type it is not difficult to improve read more
  • Residential mailboxes: Hello. This is kind of an "unconventional" question , but read more
  • Luigie Fulc: Gerade habe ich eine interessante Seite für Tricks auf Linux read more

OpenID accepted here Learn more about OpenID

Small Business Blogs - BlogCatalog Blog Directory