LegRoom.net Kick back and relax

Occasionally I have need to copy files to/from a VMware instance. The usual process for this would involve starting up the virtual machine, loading the OS, copying the files, then shutting it down and exiting VMware. However, this adds a lot of overhead to a simply file copy process. There are some easy to find utilities for doing this under a Windows host OS, but doing so under Linux has proved a bit more difficult. After a good bit of searching, I found this VMware forum post that suggested I could use a utility called vmware-mount.pl to achieve this.

Excellent. Of course, as with many things in Linux, it's not that easy.

To begin with, I had to track down a copy of the utility. I use (and highly recommend) the excellent free VMware Player to run my guest instances. It works like a champ, but unfortunately contains only a limited selection of support tools. To get a copy of vmware-mount.pl, you'll need to download the VMware Server package for Linux. Specifically, download the file labeled "VMware Server for Linux Binary (tar.gz)". This script may also come with VMware Workstation, but VMware Server, like the Player product, is free to download and use.

Once you've downloaded VMware Server, extract the contents of the tarball ( tar xf VMware-server-1.0.3-44356). Change to the bin/ directory, and copy vmware-mount.pl and vmware-loop to the bin/ directory of your installed copy of VMware Player. In my case, this this /opt/vmware/player/bin/. Verify that both scripts are executable (chmod a+x >files< if necessary).

That takes care of installing the necessary files. In order to use these scripts, however, you need support enabled for certain kernel features. Depending on your distribution this may already be enabled, but for troubleshooting purposes I'm including the three main options that I'm aware of:

• Loopback device support (allows mounting of file objects as block devices):
  Device Drivers -> Block devices -> Loopback device support
• Network block device support (not sure exactly what this does, but it's necessary):
  Device Drivers -> Block devices -> Network block device support
• Filesystem support for guest OS partition(s) (eg., FAT32 or NTFS for Windows partitions, etc.)
  File systems -> DOS/FAT/NT Filesystems -> VFAT (substitute for needed filesystems)

Note: all of these options can be compiled as modules if preferred.

Now, time to test the script. From the command line, change to a directory containing a VMware disk image (*.vmdk file). Issue the following command (substituting the name of your own disk filename):

This should like the available partitions inside the virtual disk:

In this case, I have a single NTFS partition, labeled as partition 1. Next, we'll try mounting the partition. These commands must be run as root:

These commands will create a temporary directory for testing, then mount the first partition of my VMDK file in read-only mode. You will likely be given a warning about using this program with 2.4+ kernels. In my experience it is safe to ignore this warning, so enter Y to continue. You may also be given a warning about loading the Network Block Device driver; again, enter Y to continue. If successful, switch to another console, switch to root again, and change to the mount_test/ directory. You should see a list of files and directories from the guest OS. Switch back to the first console and enter Control-C to unmount the disk.

Assuming all went well, you can now copy files to/from your virtual disk (remove the read-only switch in the above code to write to the disk). However, mounting the disk from the command line and performing all copy operations as root is not very convenient, so let's setup a method to automatically mount the disk using your standard user account. The next part of this tip utilizes techniques from my Adding Custom Actions to KDE Context Menus article, and will only work for KDE users.

To begin, we need to make KDE recognize the VMDK format by creating a file association. Within Konqueror, select Settings, Configure Konqueror.... Select the File Associations tab, then click Add... under the Known Types pane. Select application as the Group, enter the name x-vmdk, and click OK. Click Add.. in the Filename Patterns pane, enter *.vmdk, and click OK. Add another pattern for *.VMDK so KDE will recognize both cases. Enter a description, such as VMware disk image, then click OK to close the settings window.

Next, we need to tell KDE what to do with these files. Following the directions in the Adding Custom Actions to KDE Context Menus article, create the following servicemenu file:

vmdk.desktop

As you can see by the Exec line, this requires two "support" scripts, launch.sh and mountvmdk.sh. launch.sh can be found on the Adding Custom Actions to KDE Context Menus article page, and mountvmdk.sh, which is based on my mountiso.sh script from the same page, can be download here: mountvmdk.sh script. Both of these scripts must be made executable and placed in a directory in your user's path (eg, ~/bin/ or /usr/local/bin/).

The following command from mountvmdk.sh does the magic:

echo 'y' will automatically answer the question about using a 2.4+ kernel. sudo instruct the system to run the command as root (more on that later). The 1 instructs the command to mount the first partition. This shouldn't be an issue in most cases as there really isn't much of a need to create multiple partitions on a VMware disk, but keep it in mind in case you do need to work with multiple partitions. Moving along, the '-o ro' option will mount the disk in read-only mode. I'm doing this purely for safety reasons (this is a new process for me), and it should not be needed. Finally, the uid=`uid -u` option is important. This instructs the mount command to mount the disk under your regular user's name rather than as root. The id -u command will print out your uid (User ID) and pass it to the sudo mount command. Without this, you would be unable to view the files as a non-root user.

Finally, we need to tell Linux that it's ok to do this as a regular user. This is done using the sudo command. Make sure that sudo is installed on your system, then run visudo to edit the sudoers file. Explanation of the file format is way beyond the scope of this article (this simple Google search should provide plenty of examples), but you'll need to give your regular user account permission to run the vmware-mount.pl command. Additionally, if you chose to compile either the loopback network block device drivers as modules you'll need to have permission to run the modprobe command as well. Make sure that this access is only given to trusted accounts, as it can definitely be a security risk

That should do it. Save all of the files, restart Konqueror, and then right-click on a vmdk file. Select Actions, Mount VMDK from the context menu. You should now have the contents of the vmdk file accessible in a subdirectory matching the name of the original file. When finished, simply enter Ctrl-C in the xterm window to unmount the disk image and remove the temporary directory.

Much easier. :-)

One thing I love about KDE is it's incredible breadth of configuration options. I really like to tweak my environment to best suite my needs, preferences, and habits. I know what works best for me, and prefer to have my desktop environment reflect those preferences.

Despite the vast number of preferences in the KDE Control Center, there are still quite a few options for which new GUI preference setting exists. The Hidden Configuration KDE Wiki page discusses some of these options, and is worth a read if you use KDE. In particular, I was looking for a way to disable the listing and expanding of archive files in Konqueror's sidebar. This "feature" was borrowed from Windows XP (Compressed Folders), where it always bugged the hell out of me. If I wanted view the contents of Zip files in Windows Explorer then I'd unzip the damn file.

Needless to say, I was rather dismayed and disappointed when I saw this "feature" appear in a KDE upgrade. There is no GUI preference available for disabling it, but after quite a bit of internet searching I found the above Hidden Configuration page, which discusses how to do it. It's a useful resource, and I wanted to make a note of it here both for the benefit of others as well as so I can easily find the page again next time I setup KDE. :-)

If you would like to disable this feature as well, first try entering this command (as documented in the Wiki): kwriteconfig --file konqsidebartng.rc --group General --key ShowArchivesAsFolders --type bool false. You'll need to restart Konqueror for the change to take effect. If that does not work (it didn't for me), do this instead:

1. Edit ~/.kde/share/config/konqsidebartng.rc
2. Search for the option titled ShowArchivesAsFolders
3. If you ran the kwriteconfig command, you should find it under the [General] category. Delete that under [General] and instead add ShowArchivesAsFolders=false it to the top of the file
4. If you do not already have that setting in the file, simply add it to the top of the file as described in the last step
5. Save the file and restart konqueror

You should now be rid of those annoying archive folders. Enjoy.

Oh, and if you'd like to disable this feature in Windows XP as well, you can easily to so by running the following command: regsvr32.exe /u zipfldr.dll. If you choose to reenable it, you can do so simply by running regsvr32.exe zipfldr.dll.

One thing I always liked about Windows (compared to Linux) is that it's very easy to add custom actions to the context (right-click) menu for any given file types. For example, I used this ability with Universal Extractor to add UniExtract... entries to the context menu of archive files, and I use it with Open with Arguments to add Open with arguments... to .exe and .bat files. I missed that ability for quite some time once I began using Linux as my primary OS. Something as simple as extracting Zip files, for example, would require jumping to the command line and entering an appropriate unzip command^[1]. However, a while back I stumbled across a tutorial entitled, "Creating Konqueror Service Menus", and was very pleasantly surprised to discover that this allowed me to do exactly what I had wanted for so long.

I setup a few custom actions (called "servicemenus" in KDE) a while back on my home system and pretty much forgot about it since it "just worked", but since I'm now using a new desktop system at home I'm already missing these custom actions. So, I figured I'd document them here while setting them up again. Hopefully this information will help out other Linux users. Much more thorough instructions can be found in the article referenced above - my instructions should be treated as more of a reference.

To begin, you'll need to create a new .desktop file for the action you want to perform. For the purposes of this article, I'm going to add a context menu item that will extract RAR files to the current directory. So, we'll create a new file named ~/.kde/share/apps/konqueror/servicemenus/rar.desktop. The file name is arbitrary, but it must be saved in the specified location, and must end with the .desktop extension. Next open the file in your favorite editor and add the following:

rar.desktop

This code is not very intuitive, so I'll explain each option

• ServiceTypes - specifies the type of files with which the action should be associated. The easiest way to determine this information is to run Konqueror, click Settings, Configure Konqueror, and select the File Associations section. Enter the file extension you want to associate the action with (in this case, rar, and then add the listed file types to the Service Types entry. Repeat for each extension if you want to associate with multiple types
• Actions - specifies the name of the stanza that defines the action. Multiple actions can be specified, but we'll only use one here. Just make sure that the name entered here matches the [Desktop Action xxx] defined below.
• Name - the name of the context menu entry that will appear when right-clicking on the given type of files
• Exec - the action to perform when selected; more details below. Please also see this page for a full discussion of this item, including a list of valid field codes.
• Icon - the name of the icon to associate with the context menu entry (optional). This can point to a real file if you want to use a custom icon, but you have to specify the full path and filename. In this case, I'm telling it to use the package icon from the current icon set. The easiest way (that I know of) to view these "pre-defined" icons is to right-click on any K-menu entry, select Edit Item, and click on the icon button for that item, It'll bring up an icon browser. Find the icon you like best, note the name, then close the windows and add it to the Icon entry.

Now, let's discuss the Exec entry. Ordinarily you'd probably want to call the binary directly; eg., unrar x \"%f\". In this case, however, I want to get feedback on the current progress of the operation, as well as any errors that might have occured. Since unrar is a CLI application, running it from a GUI wouldn't provide any feedback. It would simply run in the background and then exit. To work around this, I created a "wrapper" script called launch.sh that will accept arguments passed by KDE and run the command in a standalone xterm terminal^[2]. Using this method, clicking the the action in the context menu will spawn a new xterm window, which will then display the current status of the operation. It will also allow you to enter any additional information that may be necessary, such as answering an overwrite prompt or providing an archive password.

The code for the wrapper script is listed below. The only dependency is that xterm must be installed in an your $PATH.

launch.sh

That should do it. Save both of those files, make sure that launch.sh is copied to a location in your $PATH, then try right-clicking on a RAR file. Under the Actions submenu, you should now see an entry called Extract Here. Click it, and if all goes well the contents of the RAR file should be extracted to that directory.

For reference, here's a list of all KDE servicemenus that I have created:

• audacious.desktop - Enqueue and begin playing all selected audio files in Audacious (originally written for XMMS, and still contains the commented code if desired)
• iso.desktop - Mount an ISO CD-Rom image in a subdirectory of the current folder to allow file browsing and copying; press Enter when complete to unmount the ISO and remove the temporary directory. This service menu requires my mountiso.sh script.
• par.desktop - Repair damaged RAR archives using associated PAR files
• rar.desktop - Extract contents of RAR archives
• tbz.desktop - Extract contents of bzipped tarballs
• tgz.desktop - Extract contents of gzipped tarballs
• vmdk.desktop - Mount a VMware disk image in a subdirectory of the current folder to allow file browsing and copying; press Ctrl-C when complete to unmount the disk image and remove the temporary directory. This service menu requires my mountvmdk.sh script. More details can be found in the How to Mount VMware Disk Images under Linux article.
• xine.desktop - Enque and begin playing all selected video files in Xine
• zip.desktop - Extract contents of ZIP archives
• launch.sh - Wrapper script to display service menu output in an xterm window; most of my servicemenus require this script

^[1] Yes, I know that I can install a GUI archiving utility such as Ark. However, that's not really relevant here for two reasons:

1. I want to right-click and extract directly withing Konqueror without first opening it in a separate utility
2. File extraction is just an easy-to-visualize simple example - there are other cases where install a separate utility is not an option or just doesn't make any sense

^[2] Yes, you could theoretically call xterm directly from the .desktop file rather than using a wrapper script, but I couldn't get it to work properly. I had issues with getting xterm and the associated command (in this case, unrar) to accept the correct path, as well as dealing with spaces in the filename. My wrapper script will handle anything that's thrown at it (so far, anyway...).

I'm a bit late posting this (I believe it's already made it to Slashdot), but Michael Stutz recently published a good article on the IBM developerWorks site entitled, "Learn 10 good UNIX usage habits." From the introduction:

When you use a system often, you tend to fall into set usage patterns. Sometimes, you do not start the habit of doing things in the best possible way. Sometimes, you even pick up bad practices that lead to clutter and clumsiness. One of the best ways to correct such inadequacies is to conscientiously pick up good habits that counteract them. This article suggests 10 UNIX command-line habits worth picking up -- good habits that help you break many common usage foibles and make you more productive at the command line in the process. Each habit is described in more detail following the list of good habits.

It contains some very useful tips. I recommend that anyone using a CLI environment, regardless of your experience level, give it a read.

Full link:

http://www-128.ibm.com/developerworks/aix/library/au-badunixhabits.html

As found via Slashdot:

microbee writes: "On LKML's periodic GPL vs. binary kernel module discussion, Andrew Morton hinted that he favors refusing to load binary modules in 12 months. Greg Kroah-Hartman then posted a patch to do exactly that. Surprisingly Linus chimed in and called it 'stupid' and a 'political agenda,' and even compared it with the RIAA's tactics. Later in the same thread Greg withdrew his patch and apologized for not having thought it through."

Linus' post is a pretty good read on this debate. If you're unfamiliar with the topic, here is a brief overview. My personal take is that FOSS drivers are definitely the way to go, but being able to actually use my hardware takes precedence. If no viable (or comparable) FOSS driver exists, then I'd rather use a binary driver then simply not have full use of my hardware.

Anyway, as I said, it's a pretty interesting read. Here's a full link to Linus' post:

http://lkml.org/lkml/2006/12/13/370