Archives 2010

Yes, you read that right – there is finally an Open Source Blu-Ray Disc player GUI for Linux, albeit unofficial and certainly very grey in legality depending on which country you are in.

lxbdplayer is the collaborative effort of four French Engineering students. What they have written is basically a frontend that combines the apps DumpHD and AACSKeys which I have used in previous Blu-Ray articles into one easy to use GUI. Decrypted BD streams are then piped into MPlayer for playback.

The end result is that you can now watch your BD movies almost as simply as a regular video player without the need to go through the process of ripping them into an MKV file first, or chewing up loads of drive space.

Now before you get all excited, this is a work in progress and you are ultimately limited to the decryption keys that have been discovered so far. You have no better ability to watch BD titles than you have with doing it all manually with DumpHD and AACSKeys. In fact, lxbdplayer already falls over in one area (for now), and that is it has no ability to process BD+ protected discs. Attempting to watch such movies will show a partially or fully corrupted video stream.

I tried using lxbdplayer with several of my BD titles under Ubuntu 10.04, and found that it played all my older titles pretty much perfectly. It’s only newer titles, especially those featuring BD+ protection that are problematic.

In short, this tool will only let you play older BD titles easily, but no doubt as DumpHD and AACSKeys progress in development, we will see those improvements filter down to lxbdplayer. I should also point out that lxbdplayer does not actually play the disc as such – it pulls out the titles available on the disc and allows you to play them by choosing them from a menu. It will not actually allow you to play the menu interfaces provided on the disc.

Your BD optical drive will also need to have been hacked with custom firmware to ignore the Player certificate, or use an imported BD drive that already ignores the Player certificates, or AACSKeys will not be able to retrieve the decryption key to decrypt the disc with.

Anyway, to use lxbdplayer, you will need to download the following:

• The lxbdplayer itself. This package is a .deb for Ubuntu and Debian.
• The AACSKeys plugin for lxbdplayer.
• The MakeMKV package (this is the 64-bit version. To get the 32-bit version, click here).
• The ShowKeys library (again, this is the 64-bit version. To get the 32-bit version, click here).

1. Install the packages by either double-clicking on them and let the GDebi installer install them, or use a terminal as follows:
   
   $ sudo dpkg -i lxbdplayer_0.2.1_all.deb lxbdaacs_0.2.1_all.deb makemkv_1.5.5b_amd64.deb libshowkeys_v1.5.5_amd64.deb
   
2. A couple of dependencies will need to be downloaded, but otherwise the installation is small and quick.
   
3. Once the install is complete, import the decryption keys needed by typing in the following command (you do not need to use sudo here):
   
   $ bdkey-install
   
4. Now you are ready to rock and/or roll.
   
5. Insert your BD movie disc into your BD drive. Within seconds you should be prompted by Gnome about what to do with the disc, and you will notice that there is a new default action for BD discs to launch lxbdplayer. Go ahead and allow lxbdplayer to launch, or alternatively launch it manually from Applications->Sound & Video->lxBDPlayer. If you manually launch, you need to tell the player where your BD title is mounted. Under Ubuntu Lucid, this will be under the /media directory.
   
6. Once your BD disc is located, lxbdplayer will process the disc for a short while before presenting you with a chapter list. To play a title, simply choose it from the list and hit the Play button. Almost right away you will see the video appear on your screen.

The player showing the video itself is simply MPlayer, and all its standard controls apply here.

Pat yourself on the back – and enjoy your movies. 

More information about lxbdplayer including screenshots, can be found on the project’s home page, but be warned, it’s all in French.

Following my article about creating your own PXE network boot server, here is the first practical use you can put it to – taking the Ubuntu Live CD and turning it into a network-bootable version!

Network booting the Live CD has obvious advantages – aside from booting faster than CD (especially on a gigabit network), it is indispensable as an emergency boot medium in a workplace environment, especially for broken Windows systems, and allows for Ubuntu effortless installations on netbook PC’s that don’t have optical drives and saves you having to have a USB stick handy.

Pre-requisites

• You need a working Linux PXE boot server. Doesn’t have to be Ubuntu, but it needs to be Linux. You cannot use a Windows PXE server.
• An Ubuntu 10.04 Live CD ISO or physical CD. Can be the 32-bit or 64-bit ISO, but you can also setup both of them at once!
• At least 700MB of drive space on your PXE server, more if you want to have more than one CD available.
• This tutorial was put together using Ubuntu Server 10.04 Lucid Lynx, but should work with all future releases and older versions to at least Ubuntu Server 8.04 Hardy Heron.

Getting it together

1. Login to your PXE server and mount the CD or ISO image (in this example we are copying the 32-bit disc). Assuming the CD is mounted at /media/cdrom, copy the CD’s files to your server as follows:
   
   $ sudo mkdir -p /srv/tftp/ubuntu-livecd-boot/i386
$ sudo mkdir -p /srv/ubuntu-livecd/i386
$ sudo cp -av /media/cdrom/* /srv/ubuntu-livecd/i386
$ sudo cp -av /media/cdrom/.disk /srv/ubuntu-livecd/i386
$ sudo cp -av /media/cdrom/casper/initrd.lz /srv/tftp/ubuntu-livecd-boot/i386
$ sudo cp -av /media/cdrom/casper/vmlinuz /srv/tftp/ubuntu-livecd-boot/i386

1. (if you want to setup the 64-bit disc, then replace all instances of “i386″ with “amd64″, or you can setup both architectures by setting up both directories)
   
2. Make sure the permissions of the files to be loaded by TFTP are correct:
   
   $ sudo chmod 777 -R /srv/tftp
   
3. The astute of you will have noticed that we have copied the Ubuntu CD outside of the TFTP directory and that we have made a separate copy of only two of the disc’s files inside the TFTP directory. Why is this? Well, the vmlinuz and initrd.lz files are the only files that TFTP will need to download to get started with the boot process. After that, we will use NFS to deliver the rest of the Live CD, so let’s set that up:
   
   $ sudo apt-get install nfs-kernel-server
   
   Note: I should point out that the files that are copied to the NFS share do not have to be on the PXE server. The NFS server can be any box as NFS is not related to PXE at all.
   
4. Once that is installed, we need to define an NFS share. This is done in the NFS exports file, so let’s get that into a text editor:
   
   $ sudo nano /etc/exports
   
5. Add the following line to the bottom of the file:
   
   # Ubuntu Live CD files for PXE booting
/srv/ubuntu-livecd/i386        *(ro,async,no_root_squash,no_subtree_check)
   
   …if you are setting up the 64-bit version, replace “i386″ with “amd64″, or if setting up both architectures, list it as follows:
   
   # Ubuntu Live CD files for PXE booting
/srv/ubuntu-livecd/i386        *(ro,async,no_root_squash,no_subtree_check)
/srv/ubuntu-livecd/amd64       *(ro,async,no_root_squash,no_subtree_check)
   
   A breakdown of the parameters on the right is as follows:
   • The asterisk means “share with everyone on this network, regardless of who they are”.
   • The “ro” parameter means to share the data as read-only.
   • The “async” parameter allows the NFS server to reply before data is written to the share. Since it’s mounted as read-only anyway, the parameter is only there to keep NFS’ syntax happy.
   • The “no_root_squash” parameter means to allow the NFS client to use the mount as a root filesystem, otherwise it’s mounted as “nobody” instead of “root”. Since the LiveCD is essentially a diskless client, we need to be able to define the NFS mount as a root volume.
   • The “no_subtree_check” parameter helps to speed up transfers. Normally NFS will check to see if a requested file exists in an exported sub-directory. This slows things down, so turning this off means the only check that is made is that the requested file exists on the exported filesystem. Subtree checking can also cause issues when an open file is renamed, but since the export is read-only, this is irrelevant.
     
6. Save your changes with CTRL+X, then “Y” and then Enter.
   
7. Now have NFS re-read its export file and begin sharing the specified directories with:
   
   $ sudo exportfs -a
   
8. We’re nearly ready to rock and/or roll. All we need to do now is prepare the PXE boot menu to launch the Live CD for us. Assuming you followed by previous tutorial and your boot menu file is called mybootmenu.cfg:
   
   $ sudo nano /srv/tftp/mybootmenu.cfg
   
9. Assuming your NFS server’s IP address is 192.168.0.10, insert the following lines for a 32-bit Live CD entry:
   
   label Live CD 32-bit
    kernel ubuntu-livecd-boot/i386/vmlinuz
    append boot=casper netboot=nfs nfsroot=192.168.0.10:/srv/ubuntu-livecd/i386 initrd=ubuntu-livecd-boot/i386/initrd.lz -- splash quiet
   
   …and if you are doing 64-bit, you can replace or add as a separate menu option the following:
   
   label Live CD 64-bit
       kernel ubuntu-livecd-boot/amd64/vmlinuz
       append boot=casper netboot=nfs nfsroot=192.168.0.10:/srv/ubuntu-livecd/amd64 initrd=ubuntu-livecd-boot/amd64/initrd.lz — splash quiet
   
   The kernel line is the actual kernel that is loaded to run the session. The append line tells the boot process several things. First up, the casper directory contains the boot files (a SquashFS image in the case of the Live CD), the root of the NFS file system is located on the server with the IP 192.168.0.10 under the path /srv/ubuntu-livecd/i386 (or amd64) and that the image to fire up the RAM disk with is located under ubuntu-livecd/i386/initrd.lz and finally we have advised the boot process to suppress console messages and display the splash screen while loading. From this point on, the initrd.lz is extracted and will grab the SquashFS image from the casper directory via NFS, extract it and commence running it. All other files that the disc needs to do its thing (such as when installing Ubuntu from the Live environment) are also provided by the NFS share.
   
10. Save your changes by pressing CTRL+X, then “Y” and then Enter.
    
11. You’re now ready to go – reboot your PXE workstation and you should now see an entry for your Live CD. Upon choosing it, your system should fire up with the Live environment! Once booted, you can even do an Ubuntu install to the PC you started on as though you’d booted from a CD or USB device!
    
    

Enjoy! 

The Preboot eXecution Environment (PXE) provides a means of starting up a PC using a network adapter instead of the traditional method of hard-drive, USB flash stick, CD or floppy disk.

Why would you want to boot a PC from the network? Well, it opens the door to booting diskless workstations, eg: Internet Cafe PC’s, or if you regularly install tens or hundreds of PC’s, you can start the installer on all those machines at once without needing to have individual boot/install media for each machine. You can even use Linux PXE for starting Microsoft Windows network installers and tools.

This article is going to show you how to setup a standard Ubuntu 10.04 Lucid Lynx Server (will also work with Ubuntu 12.04 and 14.04) to respond to a PXE boot request and present a boot menu ONLY. I will put practical applications such as installing Ubuntu over the network or booting a Live CD over the network into separate future articles.

Pre-requisites:

• A PC or virtual machine with an installation of Ubuntu Server on it. This tutorial was written using an Ubuntu Lucid 10.04 Server, but these instructions will work equally well on nearly any version of Ubuntu Server (tested and working on Ubuntu 12.04 and 14.04). This tutorial will not detail the initial build of a server as it is relatively straight forward.
• A DHCP server that allows you to specific PXE boot information. Most consumer routers will not give you these options. Suitable DHCP servers are the DHCP daemon on Ubuntu Server, third-party Linux router solutions such as Smoothwall or pfSense, and Windows Server among others.
• If your DHCP server is a dedicated network/firewall device that you do not wish to use as a file server to serve the network boot files, then you will need a separate PC to be a file server as well.
• Some free disk space. PXE booting take bugger-all space, but whatever you plan to serve from it will need space. If you plan to setup the Ubuntu Live CD to be bootable from PXE, you will need 700MB+ of hard-drive space on that server. You will need more than this if you wish to host things like multiple LiveCD’s such as both the 32-bit and 64-bit versions, or multiple different distributions.
• A PC workstation that has PXE boot capability. Any PC built in the last 10 years should definitely have this capability, though you may be required to enable it in BIOS. If you do not have a PC that can do this, you can use a virtual machine such as Virtualbox instead (you could have a virtual machine PXE boot off a virtual PXE boot server too!  ).
• A copy of Ubuntu Server 10.04 that suits your server’s architecture.
• A copy of the Ubuntu ALTERNATE Install CD 10.04 that we need to get some PXE boot files from. Unfortunately the Live CD does NOT contain the files we need.

At the end of this exercise we will have a PXE server that will boot into a selection menu that will give us choices of things to do. We’re also going to pretty up the menu with a background image instead of just having plain boring text, and we’ll do this using some of the existing elements on the Ubuntu CD as most of the work has been done for you already!

Getting it together:

1. Login to your server.
   
2. Let’s install the software we need:
   
   $ sudo apt-get install tftpd-hpa inetutils-inetd
   
   …this will install a Trivial FTP server which is essentially a super-simple FTP server plus the inetd daemon which will listen out for TFTP requests and direct them to the TFTP daemon.Before you ask, no you cannot use a regular FTP daemon like vsftpd or similar. It has to be a TFTP daemon. Beware: Ubuntu has two TFTP options in the repository – you must use the HPA version of the daemon as shown, as it handles large boot images while the other daemon does not. If you don’t use it, you will see boot errors.
   
3. By default Ubuntu sets up the TFTP daemon’s root directory to be /var/lib/tftpboot which may not suit your requirements. For the purposes of this tutorial, we will be changing this to /srv/tftp instead. To do this, we need to edit the /etc/inetd.conf file in a text editor:
   
   $ sudo nano /etc/inetd.conf
   
4. Scroll down to the bottom of the file and modify the tftp line (or add it if it’s missing) and substitute /var/lib/tftpboot bit on the end of that line with the path to your preferred directory:
   
   tftp    dgram   udp    wait    root    /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /srv/tftp

5. Save your changes by pressing CTRL+X and then “Y” and then Enter.
   
6. Now we need to tell the Trivial FTP daemon where our TFTP root is. Open its config file with:
   
   $ sudo nano /etc/default/tftpd-hpa
   
7. Modify the TFTP_DIRECTORY line (usually the fourth line from the top) to be /srv/tftp:
   
   # /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"
   
8. Save your changes by pressing CTRL+X and then “Y” and then Enter.
   
9. Now we just need to restart the inetd and tftp services with:
   
   $ sudo service inetutils-inetd restart $ sudo service tftpd-hpa restart
   
10. So that’s the TFTP daemon ready to serve files to a PXE agent. Now we need to create the directory where we will be putting all our PXE goodness into:
    
    $ sudo mkdir -p /srv/tftp
    
11. We now need to copy some files off the Ubuntu Alternate Install CD that make up the PXE boot files and the menu config files. I will use the 32-bit disc in this example, though the files are the same on the 64-bit disc for this step. Insert the CD or mount the downloaded Ubuntu Alternate Install CD ISO. In this case I will assume you have a physical CD mounted at /media/cdrom.
    
    $ sudo cp /media/cdrom/install/netboot/pxelinux.0 /srv/tftp
$ sudo mkdir -p /srv/tftp/ubuntu-installer/i386
$ cd /media/cdrom/install/netboot/ubuntu-installer/i386
$ sudo cp -R boot-screens /srv/tftp/ubuntu-installer/i386
$ sudo cp initrd.gz linux /srv/tftp/ubuntu-installer/i386
    
    (if you’re using the 64-bit CD, substitute all instances of “i386″ above with “amd64″ instead.)
    
12. Now we need to setup the initial PXE boot process:
    
    $ sudo mkdir /srv/tftp/pxelinux.cfg
$ sudo nano /srv/tftp/pxelinux.cfg/default
    
13. You will now be looking at a blank text editor. In this, type the following:
    
    include mybootmenu.cfg
default ubuntu-installer/i386/boot-screens/vesamenu.c32 prompt 0
timeout 100
    
    The timeout 100 line will provide a 10 second countdown before it automatically chooses the default PXE menu option when you boot into it. If you do not want a timeout, then change this to timeout 0 instead.
    
14. Press CTRL+X and then “Y” and then Enter to save your changes.
    
15. Now let’s setup our actual boot menu that we’ll be choosing options from:
    
    $ sudo nano /srv/tftp/mybootmenu.cfg
    
16. Again you’ll be looking at a blank text editor. Type (or copy & paste) in the following. Indenting text is not important, but makes it more readable:
    
    menu hshift 13
menu width 49
menu margin 8
menu title My Customised Network Boot Menu
include ubuntu-installer/i386/boot-screens/stdmenu.cfg
menu begin Cool options
    default myfirstoption
    label myfirstoption
        menu label This is a menu item
    label mysecondoption
        menu label This is another option
menu end
    
17. Press CTRL+X, then press “Y” and then Enter to save your changes.
    
18. Finally, we need to change the permissions of all files concerned because TFTP will not read any files unless they are set to full access:
    
    $ sudo chmod 777 -R /srv
    
19. That’s PXE server side ready to go. Now we need to tell PXE clients where to find the PXE boot server. If you are NOT using Ubuntu as your DHCP server, then skip to step 23, otherwise do the following:
    
    $ sudo nano /etc/dhcp3/dhcpd.conf
    
20. This opens up the DHCP config file into your text editor. Assuming your PXE server is at 192.168.0.10, scroll right to the very bottom of this file and add the following:
    
    next-server 192.168.0.10;
filename "pxelinux.0";
    
    (note the semi-colon on the end)
    
21. Press CTRL+X, then “Y” and then Enter to save your changes.
    
22. Restart the DHCP daemon with:
    
    $ sudo service dhcp3-server restart
    
23. If you’re using a non-Ubuntu DHCP server, then look for any “network boot” options and specify the PXE boot server’s IP address and path to the pxelinux.0 file there. For example, in Smoothwall, you would go to Services->DHCP and then check the “Network boot enabled” checkbox, then specify “192.168.0.10” (to suit our tutorial) into the “Boot server” box and “pxelinux.0″ in the “Boot filename” box and “/srv/tftp” in the “Root path” box.

24. We should now be ready to try out our PXE boot server! On your test workstation or VM, enable booting off the network (in the case of PXE booting a Virtualbox VM, you must ensure that the network adapter is set to “bridged mode” instead of “NAT” and fire away. You should first see your PC launch its PXE agent, looking for a DHCP server to tell it where the PXE server is:

25. If your PXE server is working, within a few seconds you will see your boot menu!

25. …and if you hit Enter on “cool options” you will now see a sub-menu showing your two options that we created.

26. Well this is all well and good, but the menu currently doesn’t actually DO anything other than show us a bunch of options. How about we provide something, say the Memory Test application from the Ubuntu Alternate Install CD? Plus we’ll add an option to boot from the first HDD in your system. If your CD is still mounted on the server, then go back into the terminal you’ve been working in and copy over the MemTest app as follows:
    
    $ sudo cp /media/cdrom/install/mt86plus /srv/tftp
    
27. Now let’s add a menu entry for it:
    
    $ sudo nano /srv/tftp/mybootmenu.cfg
    
28. Modify the file so that it now looks like the following (add just the bolded lines):
    
    menu hshift 13
menu width 49
menu margin 8
menu title My Customised Network Boot Menu
include ubuntu-installer/i386/boot-screens/stdmenu.cfg
label Boot from the first HDD
    localboot 0 label Memory Tester
    kernel mt86plus
menu begin Cool options
    default myfirstoption
    label myfirstoption
        menu label This is a menu item
    label mysecondoption
        menu label This is another option
menu end
    
29. Save your changes and exit.
    
30. Ensure the permissions of everything, including our newly copied files, have the correct permissions for TFTP to work:
    
    $ sudo chmod 777 -R /srv
    
31. Reboot your test PC via PXE and this time you will see your menu sports the new menu options at the top (you could have equally placed them at the bottom too):

32. Choosing “Memory Tester” from the menu will launch the MemTest app straight away, just like off the CD.
    
    But by now you are probably wondering “Aren’t we building off Ubuntu 10.04? Why does the menu have the old logo on it? Can we change it?”
    
    Sure, we can!
    
33. The Ubuntu 10.04 installer CD has got the new Ubuntu logo, but for some reason it’s only saved as a PCX file which won’t work for the PXE boot menu. We can fix this by simply re-saving the PCX file as a PNG file. To start with, get a copy of the splash.pcx file from the /isolinux directory on the Ubuntu CD. This is the new Ubuntu logo that you normally see on the CD’s boot menu.
    
34. Load this file into an image editor such as The GIMP and re-save it as a PNG file, eg: splash.png (of course there’s nothing stopping you from creating your own graphic either – just make sure it’s no greater than 640×480 in size and indexed down to 16 colours).
    
35. Copy the re-saved image file into /srv/tftp/ubuntu-installer/i386/boot-screens and overwrite the original splash.png file.
    
36. Ensure that the permissions of the newly added file is set correctly again with:
    
    $ sudo chmod 777 -R /srv/tftp
    
37. And when you reboot your PXE workstation again, your menu will now look like:
    

32. And there you have it. A working PXE server with menu!

I will document further uses of the PXE boot facility in future articles, including how to boot the Live CD environment without the CD or a USB key, setup the ability to use your local Ubuntu mirror as an installation source for new installs, how to launch tools like Clonezilla and DBAN, and also how to setup a diskless boot system that uses PXE to do a normal Ubuntu desktop boot directly off the network without a local hard-drive.

Stay tuned! 

The release of Ubuntu’s brand new look in Ubuntu 10.04 Lucid Lynx Alpha 3 brought mixed reactions, but probably none more so than the decision to move the window minimise, maximise and close gadgets from their traditional placement on the upper-right corner of the window to the upper-left side ala Apple Mac.

Many people, myself included, do not like this. To fix it and make it look like this:

…is very easy to do. Read on.

Simply open up a terminal and type in the following at the $ prompt:

$ gconftool -s /apps/metacity/general/button_layout -t string ":maximize,minimize,close"

Viola! Instant fix! But how does it work?

Gnome is highly customisable. One of its configuration options tells Metacity where and in what order to render elements on a window. In this case, the string “:maximize,minimize,close” means to render the “maximise”, “minimise” and “close” gadgets in that order, and the colon at the start means to render them on the right side of the window. If you change the colon to be on the far right, your window gadgets will appear on the left of the window.

Don’t like how the Ubuntu team have also changed the maximise and minimise button order around? Be a rebel! Change it back by replacing the configuration string above with “:minimize,maximize,close”.

Play around with it and enjoy. 

I regularly deal with external hard-drives, be it for data backup or if I’m rescuing a client’s hard-drive from uncertain death.

Since the idea of opening my PC on a regular basis to connect a drive is a bit of a turn off, I used to use an external USB drive enclosure. This works fine, but it’s a bit slow (well, at least until USB 3.0 makes its debut). The eSATA standard allows you to connect external drives at full SATA speed, but it’s not cost-effective to buy an enclosure for every external drive you have.

Enter the Docking Bay. This is a simple weighed base that allows you to connect a hard-drive in a similar way to how you used to plug in game cartridges into a classic game console like the Atari 2600. You can then eject the hard-drive and plug another one in, all without restarting the PC.

This is a review of one such Docking Bay and how it works with Ubuntu, including the wonders of hot-swapping.

I came across this generic eSATA Docking Bay whilst browsing my local PC store. eSATA Docking Bays have been around for awhile now, but I never got around to getting one so I figured I may as well try this one and see how it went under Ubuntu.

There is unit was branded “A-Power” but I’ve seen several of these drives with various brand names on it, so this one is as generic as they come, but it comes in one of three variants:

1. eSATA and USB Docking Bay
2. eSATA and USB Docking Bay with in-built USB card-reader
3. USB-only Docking Bay with in-built USB card-reader

In my case, I got the first variant as I already have a separate card-reader.

Hooking Up

The Docking Bay is very easy to hook up. The package comes with the following components:

• The Docking Bay unit
• Power Supply
• eSATA cable
• USB cable

After connecting power, the Docking Bay is connected to the PC by the eSATA cable to a spare eSATA port on the back of your PC. You then insert the hard-drive into the slot on the top of the unit – it caters for both 3.5″ desktop hard-drives and 2.5″ notebook hard-drives. Once inserted, power on the drive using the power button at the back of the unit. The power light on the top of the Docking Bay will light up and you can now switch on your PC.

Configuration

eSATA Docking Bays don’t actually need any configuration as such. If you wish to make use of SATA’s ability to hot-swap, you will need to enable the Advanced Configuration Host Interface (AHCI) in your PC’s BIOS. Not every motherboard has AHCI, but if your machine is a recent machine, you should have AHCI capabilities. If you do not enable AHCI, you can still use your Docking Bay, however you will not be able to hot-swap a new drive without shutting down your PC first.

Using the Docking Bay

Drives inserted into the Docking bay appear like any ordinary permanently installed hard-drive inside your PC. You can format them, partition them, read and write data to them and see their SMART status like any other drive.

Doing an unscientific benchmarks using the dd app with a 7200rpm Seagate 1TB HDD, I was able to write straight zeros to the drive at a rate of about 116MB/s and read at about 120MB/s.

Real-world file copying transferred data at about 86MB/s which is consistent with normal single-drive copy speeds.

Doing a fresh installation of Ubuntu Karmic 9.10 on the hard-drive and booting my system from the docking bay and then repeating the boot test with the drive attached directly to the internal SATA connection as normal, Ubuntu booted in precisely the same amount of time, as one would expect. I was also able to dual-boot Ubuntu with Windows 7 without any issue.

Hot-swapping works well also. While Ubuntu is running, I insert my hard-drive into the dock, power on the drive and wait a few seconds. The drive appears in the Places menu, you choose it, enter your sudo password to mount the drive, and the drive appears on your desktop. When you are done with the drive, you simply do a right-mouse-click on the drive’s icon, choose “Unmount” and wait for any data to be written to the drive. Once the drive icon disappears off the desktop, you can then power off the drive in the docking bay, then press the eject button to remove the drive.

Dealing with differently sized drives, I tried a half-height Seagate 500GB I have (see photos). The spring-loaded flap on the top of the drive was able to hold the drive in place without a problem. Trying with a 2.5″ notebook HDD, the docking bay provides a cut-out section that allows you to insert the 2.5″ HDD but the flap does not press directly against the drive.

Conclusion

The convenience of a hard-drive docking station cannot be understated. This unit provides a simple, effective interface. For AUD$25 it’s cheap and in the last couple of months I’ve been using this unit, it has proven to be very reliable.

While this unit is not exactly the most elegant-looking of devices, it does the job and does it well.

Review score: 9 out of 10

Virtualbox is a great desktop virtualisation tool, but one of its annoying installation niggles is that when you setup and run a virtual machine you can’t attach any USB devices to it at all because all your USB options in Virtualbox are greyed out.

There are a raft of different solutions to this problem out there ranging from adding an extra line to the /etc/fstab file to modifying your udev rules, but the real cause of this problem is simply that your login name does not have permission to access Virtualbox’s USB driver which interfaces itself between the VM’s virtual USB hardware and your real USB stack.

During the initial installation process, Virtualbox sets up a new group called vboxusers, but it doesn’t put your login name into it. Since using USB in Virtualbox occurs at the device level, your normal user permissions that allow you to run up virtual machines in general are not enough to manipulate Virtualbox’s USB driver. As a result, you cannot tell Virtualbox to attach a given USB device to your virtual machine.

Like most things, this is easily fixed of course.

1. If your login name is johndoe, all you need to do is jump into a terminal and type in:
   
   $ sudo adduser johndoe vboxusers
   
   …which will add the user johndoe to the vboxusers group.
   
2. Now close all applications and windows, and log yourself out of Ubuntu. You don’t need to reboot, but you can if you’re the kind of person who enjoys the subtle pleasures of watching your PC start up.
   
3. Log yourself back in again as normal. This will read in your new group membership.
   
4. Fire up Virtualbox and start your virtual machine(s) as normal. You will now find that you can attach USB devices to all your VM’s via the Virtualbox Devices menu without any further ado.
   
5. Pat yourself on the back – you’re done. 

Until Sun Microsystems modify the deb installer to add the current login to the vboxusers group during install, these instructions should apply to just about any version of Virtualbox sporting the problem, on any Linux distro. 

Ubuntu 9.10 (Karmic Koala) has a curious bug on the 64-bit Intel/AMD version whereby on some systems you can play Flash perfectly, but the Flash application does not recognise any mouse clicks in it. This means in sites such as YouTube, you can’t click the mouse to play and pause, or seek in a video – you’re forced to use the keyboard.

This is a known bug with the flashplugin-installer package and is currently being worked on by Canonical. In the meantime, if you wish to fix the problem yourself now rather than wait for the official fix, just follow these instructions…

1. After you have installed Flash in the usual manner, open a terminal and type in the following:
   
   $ sudo gedit /usr/lib/nspluginwrapper/i386/linux/npviewer
   
2. Once the GEdit text editor (or substitute your favourite) opens, insert the following line just before the last line (should appear in most installations as the fourth line out of a total of five lines):
   
   export GDK_NATIVE_WINDOWS=1
   
3. Save your changes and exit your text editor.
   
4. Now restart any applications that use Flash, such as Firefox.
   
5. In the case of Firefox, go and visit a page that uses Flash. You should now find that you can now click in Flash without a problem.
   
6. Pat yourself on the back. You’re done.

You do remote tech support for clients. One client calls you up needing assistance. You SSH into their machine as usual to check out the problem. You probably also have them on the phone so you can walk them through what you are doing or ask them questions, but making long support phone calls can be expensive if you’re doing it via a mobile phone or internationally and it’s tiresome to switch to an IM client window all the time to write comments, especially if the client is not running a graphical session and only has a text server console to look at.

Sometimes actions speak much louder than words, and it would be great for the client to be able to see what you are doing without cumbersome and bandwidth-hogging remote screen tools like VNC. Is there an easy way to collaborate in a terminal?

There certainly is…

1. First up, login to the client’s remote machine in question using their login, eg: login to the PC at 192.168.0.27 with the username “fred”:
   
   $ ssh fred@192.168.0.27
   
2. Once logged in, we need to create a screen session. It needs a name, so I’ll call mine “blah”, but you can make it any name you want. Type in the following (note that the “-S” parameter is uppercase):
   
   $ screen -S blah
   
3. Now instruct the client to open a terminal locally and attach themselves to your screen session by typing in the following command (note that the “-x” parameter is lowercase):
   
   $ screen -x blah
   
4. You are now both looking at a common screen session. Anything that either of you type along with any command output will be automatically and immediately seen by the other person in real-time!
   
5. Once you’ve finished sorting out the client’s problem, terminate the screen session with:
   
   $ exit
   
6. You and the client will be both returned to your regular local terminal sessions which you can now close with the “exit” command again.

If you don’t have another machine to try this with, you can try it using two terminal windows on your own local machine. You don’t need to SSH in since you’re already logged in, just run both screen commands in their own respective windows and watch as any new information entered, including command output, appears in both terminals simultaneously.

You are not limited to only having two terminals sharing a screen session – you can have an unlimited number of terminals, remote or local, share one screen session.

Note that the shared screen session only works with the same user login. You cannot have two separate users share a screen, hence the need to login using the client’s username before setting up the screen session. If the client’s username does not have sudo rights, once inside the screen session, simply su to your admin login and then do the administrative work you require, all while your client watches on in amazement. Of course, be aware that the client can also start typing in commands whilst you are su’ed into your admin login as well, so don’t leave your terminal unattended.

Enjoy.