Messing with your head

Just wanted to post an update informing folks that it may be a little while before I get anything else meaningful up on here. I just got back from the NRF Conference, and this weekend I head back out to Palo Alto for some awesome training back at VMware HQ. Shortly after that I’ll be heading to PEX 2012 to talk about PCoIP – so I may see some of you there – and then it’s off to Singapore and possibly London. This covers my schedule pretty much through March with only a week here and there back in the home office.

I realize there’s been a bit of an outpouring of posts the last few weeks so I didn’t want the sudden “silence” to scare people away or to give the impression that the blog went dead. I’m here, happy to answer questions directly or via comments (comments preferred as then it’s preserved for everyone) but I don’t expect to have time for any new serious content generation for the next 8-10 weeks (or so). That being said I do have some really good ideas for content brewing so I look forward to the future and an opportunity to lock myself back up in the dungeon to turn out some new content.

Until then, I’ll see you at PEX 2012 perhaps, or failing that, I’ll meet you back here in a few weeks.

-Chuck

This post continues my efforts to provide information on how to use the VMware View Client for Linux in fun and interesting ways. This time, we’re going to use the output from my last post on extracting the VMware View Client from the Ubuntu .DEB file to create a new live CD on a different distro – in this case OpenSUSE 12.1. Further we’ll be using SUSE Studio to create the ISO.

As always, let’s get this out of the way-

DISCLAIMER: This process is in no way supported by VMware. Use the extracted VMware View Client and subsequent OpenSUSE live CD ISO at your own risk. Neither I, nor VMware Inc. make any warranties that either of these artifacts will work for you in any way, in fact they may explicitly harm you and your family if you are not careful – but probably they won’t. Do not contact myself or VMware Inc. for support when utilizing either the extracted files or the OpenSUSE live CD ISO containing them. You have been warned.

Moving on…

SUSE Studio

First let me say that I have been a huge fan of SUSE Studio since the moment I got into the beta for it. I have always thought that it is not only easy to use but also very powerful – a rare combo indeed! If you have never heard of it before I like to describe it as a wizard-driven Linux appliance factory. Admittedly that description probably sucks, but that’s what I like to tell people who have never heard of it – therefore they can’t easily argue with me about it. By the time they go and see it for themselves I am usually long gone.

Getting started

In order to use SUSE Studio you will need to have an account, thankfully SUSE Studio supports OpenID, so if you don’t have an existing Novell account, you can sign in with a pretty board range of other accounts you likely already have:

Once you get logged in, you are brought to your homepage. Here, you will find any previously built appliances and you’ll be given the option to create a new appliance. As that’s exactly what we are here to do, go ahead and click it.

Template Selection

Once you do that you will be taken to base template selection. This is the one item you only get to pick once, so make it count! There are several options you can choose from including the most recent OpenSUSE release, the most recent SLES release, and the previous SLES release. Within each section are multiple configurations targeting different deployment scenarios ranging from JeOS (Just Enough OS or “Juice”) to a text only server to a full blown desktop client with all the fixin’s.

For this tutorial we want to select the openSUSE 12.1 Minimal X base template and the 32bit architecture. We’ll also name this appliance ‘VMware View LiveCD’.

Once you are done, click ‘Create appliance’ and you will shortly be taken to the ‘Start’ tab of the SUSE Studio wizard.

The Start tab

After template selection, you’ll notice some key stats and a little thumbnail preview of the visual “look” of your appliance on the left. This will update automatically as you change the appliance configuration. On the Start tab all you can do is change the name of the appliance. The wizard suggests that we move on to the ‘Software’ tab, and I concur.

The Software tab

Now we are getting somewhere. Stuff to do! This tab is where you can add just about anything you like to your base template. Anything in the SUSE repositories is immediately available, and you can add additional repositories or even just directly upload your own custom RPMs to be applied to the base template during the appliance build. Much like any modern Linux install you can select pre-grouped patterns such as “Games” or “Java Development” which will install all required packages and dependencies or you can select individual packages and let the robot looking version of Clippy determine the requirements and deps automatically.

In order to satisfy the requirements of the VMware View Client we will need to add a few libraries. I’ve gone through the hell of finding out what’s already included in the base template, and what needs to be added so I’ll spare you the details. In short, the following packages will need to be added:

• libopenssl0_9_8
• libpng12-0
• libatk-1_0_0
• libgtk-2_0_0
• libgdk_pixbuf-2_0_0

You will add these packages by entering them into the ‘Search for software’ text box and then clicking the ‘+ add’ button next to them.

Once you have added all the required packages it is time to move on to the ‘Configuration’ tab.

The Configuration tab

This is where you’ll likely spend the meat of your time when making a new appliance. There are several sub-tabs here and we will go through each one. Let’s get started…

General

This sub-tab is where you will add users, configure basic networking and firewall rules, set time zone, and configure language/locale info. For this build I tweaked a few things – disabled the firewall, and switched the user account name to ‘view’. I left all passwords at defaults for the sake of this build, but I don’t recommend doing that in the real world.

 Personalize

Here you can tweak the appearance of your appliance via a custom logo and/or background. I took a moment to whip up some custom artwork (available here and here) and uploaded them to make this appliance look a bit more VMware View-ish. You are free to peruse DeviantArt or 500px for your custom artwork though. Experiment.

Startup

This sub-tab controls the default runlevel of the appliance (leave it alone here – 5: Graphical Login) and allows you to add a EULA to the appliance if you require one, for our work here, we don’t, so leave it be.

Server

Another sub-tab where we don’t need to touch anything, we have no database installed, and want to keep it that way.

Desktop

Ah! Something we care about again! Here we will configure the appliance to auto login as the ‘view’ user we created back on the ‘General’ sub-tab and we’ll also setup the VMware View Client to be automatically started once the user is logged in.

Check the box to ‘automatically log in user’ and select ‘view’ from the dropdown box (should be the default).

Next, click ‘Add new autostart program’. In the ‘Command’ box enter:

/usr/bin/vmware-view --fullscreen

Select ‘view’ in the ‘Start for user” dropdown, and enter “VMware View Client” in the comment (or don’t). Lastly, make sure the ‘Enabled’ check box is in fact checked – otherwise we just did all this work for nothing.

 Appliance

This sub-tab isn’t terribly relevant to running our appliance as a live CD except for a few options towards the bottom of the page. Primarily this is to configure the RAM and disk attributes when deploying the appliance as a virtual machine.  Since we are only looking to make an ISO right now don’t mess with those settings, they won’t have any impact.

The one location we do care about here is the ‘Additional Options’ section.  Here we are presented three options:

• Add live installer to CDs and DVDs
• Enable VMware CD-ROM support
• Enable WebYaST

If you want to build a live CD that also supports installation, leave ‘Add live installer to CDs and DVDs’ checked. But be aware this will increase the size of the resulting ISO a bit. For now,  deselect that option and leave the others as-is.

 Scripts

This sub-tab will allow you to execute scripts at the end of the build process and/or each time the client boots. Again, for the sake of simplicity we’re going to skip adding/changing anything here but when trying to reduce the size of your ISO/image file the ‘end of build’ script can be a very powerful tool to run through and delete unneeded files and directories. I suggest re-visiting these options after your initial build if your interest lies in minimizing the ISO footprint.

That wraps up the ‘Configuration’ tab settings. Now we’ll move into the ‘Files’ tab.

The Files tab

Up till this point you may have been wondering when or how the actual VMware View Client itself was going to get installed. Well, wonder no more! This is tab is where we will add the .tar.gz file created from extracting the VMware View Client out of the Ubuntu .DEB file.

The ‘Files’ tab allows you to add pretty much any kind of file you like to the base template. This is incredibly useful if you’ve made an archive of many specific settings/properties files and just want to lay them in over the base image.  It’s also a great place to drop in custom or home-built software which is what we are going to do right now.

Click ‘Upload file…’ and navigate to the location where you placed your extracted VMware View Client .tar.gz archive. Wait for it to upload, and we are done. In this case all the default settings are what we want – the archive should be extracted into ‘/’ or the root directory and since permissions will be preserved we shouldn’t need to touch those.

 The Build tab

And now the magic happens. The Build tab is where you configure how you would like your appliance to be “output” – what formats it will be created in.

Since our goal here is to make a live CD let’s set that to the default. Choose ‘Live CD/DVD (.ISO)’ from the drop down list.

With that setup we can now kick off  the build of the live CD. Click ‘Build’ and go grab something to drink. Or you can peruse this captivating gallery of a build in process:

The build is complete. Now we get to one of the coolest features of SUSE Studio – the testdrive! You’ll notice this option to the right of the final build size for your appliance. Clicking it will launch a new browser window and will load your appliance into a virtual machine. The console for the machine opens in the new browser window and you can interact with it from there. It’s important to note that NO outbound network traffic is allowed from a testdrive, it’s just there to let you verify and modify the configuration of your appliance before wasting the time and bandwidth to download it. It’s an incredibly useful tool. One other note is that if you look carefully you’ll see that the version number of your appliance has been auto-incremented. This will happen on each build. You can of course set your own specific version number but this is also a nice touch.

Let’s take this appliance for a testdrive…

As you can see the custom logo and background are present and looking rather dapper. One thing that could be changed is the bootloader timeout – it should probably be reduced to 0. That would be a good thing to add to a post-build script or apply via a configuration file archive but for now I will leave that as an exercise for the reader. You can also see that the VMware View Client launches automatically in full screen mode so all a user would see is the prompt to connect and login.

Closing Thoughts

So that’s it. We have a good basis for a PC re-purposing live CD built quite easily and quickly via SUSE Studio. It’s substantially smaller (230MB) than the Ubuntu live CD I showed you how to build previously, but to be fair, no time at all was spent on optimizing that image. Still, I think it’s quite a bit easier to build an image via SUSE Studio than to use UCK and manually strip out significant portions of the OS. However, this method also means you’re completely unsupported but as Captain Kirk once said, “Risk is part of the game. You want to sit in that chair?”. Well, do you?

This post gives just enough information to build a starting point. There are several tweaks and enhancements that can be made from this point:

• Adjust bootloader timeout to 0 to avoid users doing whatever it is that users do when they break stuff
• Add a script to determine the proper VMware View Connection Server and pass it in via command line to the VMware View Client
• Add a script that locks the user into the VMware View Client so that when they exit it, or logoff from a desktop it automatically relaunches
• Re-enable the firewall and open only the required ports
• Prune the image to reduce overall size. It’s not bad right now, but could probably get under 200MB with a bit of effort and probably to about 150MB with a bit more

I hope you find this information useful. Post in the comments if there’s another distro you’d like to see me mess with, or if you already have and have had success.

That’s all for now.

Continuing on the thread of how to utilize the recently released VMware View Client technical preview for Linux I wanted to cover a method for extracting the “raw” client bits out of the Ubuntu package which will set the stage for moving the client to other distros in an easy and portable fashion. But first…

DISCLAIMER: This process is in no way supported by VMware. Use the extracted VMware View Client at your own risk. Neither I, nor VMware Inc. make any warranties that the extracted files will work on any Linux distro outside of those listed as supported by VMware Inc. itself. Do not contact myself or VMware Inc. for support when utilizing the extracted files. Stay safe out there people.

Ok, with that out of the way, this is actually a relatively simple process.

Step 1: Acquire the .DEB file

The first step is to acquire the .DEB file for the VMware View Client directly. The file we are looking for (currently) is ‘vmware-view-client_1.3.0-0ubuntu1+oneiric2_i386.deb’. I am certain there are countless ways to do this but I just went to pkgs.org and searched for ‘vmware-view-client’ which turned up exactly the results we are looking for.

Go ahead and click the Ubuntu 11.10 link (it really doesn’t matter which one you choose) and follow through to the download section, select a mirror, and download the .DEB file. Be careful to dance around the many and varied advertisements mixed in among the actual links.

You can choose to download the file anywhere, just make sure you can access it from a Linux distribution (I’ll be using Ubuntu here) as that’s where we will be extracting the contents of the file out. For ease of use I just downloaded the file directly to my Ubuntu instance via Firefox.

Step 2: Extract the files from the .DEB

Now that we have the installation file we need to extract the parts we care about out of it, namely the VMware View Client binaries  and support files.

We do this by changing into the directory where you downloaded the .DEB file and using the following command:

ar xv vmware-view-client_1.3.0-0ubuntu1+oneric2_i386.deb

This will leave you with 3 new files:

• debian-binary
• control.tar.gz
• data.tar.gz

data.tar.gz is the file we care about. This file has the “guts” of the VMware View Client. The other files contain code or information used for package management which we’re not going to worry about for the moment.

Step 3 – Fix the broken stuff

Now that we have the file we need, you would think we could simply rename ‘data.tar.gz’ to something like ‘vmware-view-client.tar.gz’ and be good to go. But first, we need to fix a few things in the package to make it more suitable for use in a live CD situation. Namely the fact that Ubuntu uses Zenity to display the initial EULA and we’re trying to reduce requirements, not increase them. There’s also an issue where no arguments will get passed through to the actual VMware View Client executable (/usr/bin/vmware-view.bin). This is a legitimate (but trivial to fix) bug. Let’s take a brief diversion to look at why this occurs and how it can be fixed as this is probably something you want to do on any installation of the VMware View Client so that you can utilize command line arguments to control its behavior.

First we need to extract data.tar.gz so we can get to the bits in question. From the folder where I extracted the .DEB, I created a folder called ‘client’ and then dumped the contents into there:

mkdir client
tar -xzf data.tar.gz -C client

Then, within that folder we need to move into the usr/bin directory:

cd client/usr/bin

Within that folder you will see ‘vmware-view’ and ‘vmware-view.bin’. The first file is actually just a launcher script used to display a EULA and then launch the second. Lets take a look at ‘vmware-view’:

vi vmware-view

Here we can see that Zenity is used to pop up a message box with the tech preview EULA and then create (touch) a file denoting it’s acceptance. Since we’re already off the rails as far as support goes here there is no good reason to accept the EULA anyway but the real reason to get rid of this bit of code is to eliminate the requirement for Zenity on a live CD. Next, we see that the “real” client is launched – but something is missing here. No arguments get passed in! So if you were to type:

vmware-view --help

All that would happen is that the VMware View Client would launch as if you had passed nothing in. Same for any other option. Why? Because this wrapper script is gobbling up the arguments and not passing them into the “real” view-client.bin executable so it will never know that you specified full screen operation (–fullscreen), or anything else. So, how do we edit this file? It’s easy. Now, this assumes you actually WANT to keep the wrapper in place because when we are done editing it, there’s almost no reason to have it there at all… almost.

Here is what the edited file should look like:

Pretty pathetic right? It’s also pretty pointless, but once again, in IT we deal with pointless on a daily basis so why stop for this article. Let’s talk a bit about what’s been changed here. First and most obvious, the entire EULA/Zenity code block has been removed. Second, on the launch line for ‘vmware-view.bin’ we have added ‘$*’. If you are unfamiliar with this notation it represents all of the arguments that were passed into the shell script, specific arguments can be referenced as ‘$1′ or ‘$2′ but since we don’t want or even care about specific arguments here we just take them all and pass them as the arguments to the VMware View Client binary itself. Now when you type ‘vmware-view –help’ you will actually get the help output.

So why is this pointless? Because all it is doing is calling the binary file. We could just call that directly ourselves. By removing the EULA we remove the whole point of wrapping the launch of the VMware View Client in the first place. So, a better solution might be to delete the current ‘vmware-view’ shell script, and replace it by renaming ‘vmware-view.bin’ to ‘vmware-view’. I say it MIGHT be better because there may be some very good reasons to leave the (pointless) wrapper script in place for right now:

• In a truly stateless PXE boot environment, you may want to have code that goes out and pulls a list of viable VMware View Connection Servers and then decides which host is best for that client (based on IP or some other property), and passes it in automatically to the VMware View Client upon launch.
• You may want to lock the user into the VMware View Client via an infinite loop
• You may want to provide a custom dialog to the user to allow them to select screen resolution, or possibly (with proper USB support) what kind of workstation configuration they have and then build the proper command line to attach devices unique to each configuration.
• You might want to perform some kind of file share or other mapping prior to launching the VMware View Client.
• You might want to gather stats on the client device – CPU, RAM, NIC/MAC, etc. and report them to a central database for hardware refresh/repair assistance
• Any of a million other things you MIGHT want to do before dropping a user into their VMware View desktop

So, if you think you will NEVER need to do those things, delete the script, and replace it with the binary. But if you believe you might want to be able to take some actions before launching, this might be a good place to do it, and by leaving the file in place now you have an easy way to make it happen as well as a file that’s easy for an end user to remember and execute. Yes, yes, I know you could do all those things I listed via rc init scripts at boot, but those only run once. What if you need to check the environment and apply settings or changes to the arguments every time the VMware View Client is launched? Then you’d end up wrapping it anyway and be right back where we are now. Being a PERL hacker I understand TMTOWTDI so I don’t claim this to be the only or best way, but it makes sense to me to leave the wrapper in place for now vs. renaming the binary. Ok, horse, dead, beaten.

Step 5 – Re-seal the package

We’ve extracted what we need from the .DEB, and now we’ve removed a dependency and fixed a minor bug in the contents. Now we need to seal everything back up into a nice neat bundle. No real surprises here – as it has risen from a tar.gz, so it shall be reborn!

One note, since all the permissions have been flipped to our user during extraction, and they started out as root, let’s flip them back to root when creating the archive. Change directory to the ‘client’ directory that we extracted ‘data.tar.gz’ into, and from there run:

tar -czf ../vmware-view-client_1_3_0-0.tar.gz --owner=root --group=root ./*

This command will create a new archive called ‘vmware-view-client_1_3_0-0.tar.gz’ in the initial folder where ‘data.tar.gz’ was extracted. All files in the archive will be owned by root, and all paths will be relative – which is as things were in the original archive.

Step 6 – Go forth and multiply!

So now you can take your newly created tar file and test it out on other distros. Sure, I could have converted the .DEB into an .RPM or whatever, but a tar.gz is pretty much universal and in many cases package managers are removed to create truly tiny distros anyway making this an ideal method of installation. Besides if you really want to create an RPM or other package you can easily find the steps to do it – go fish my friends! Go fish!

Installing the VMware View Client this way is fairly trivial:

sudo tar -xvzf vmware-view-client_1_3_0-0.tar.gz -C /

And that’s it. Run ‘vmware-view’ and the client should launch assuming all required deps are in place. If they are not you’ll get an error telling you so and you can then start chasing them down. If you want a list of required deps, extract the control.tar.gz file and then view the contents of ‘control’. Under the ‘Depends:’ section you will see the list of pre-reqs required:

Closing Thoughts

Now that we have a portable (kinda) installation of the VMware View Client, what can we do with it? I’ll have a follow-up post fairly soon showing what can be done with SuSE Studio. Keep an eye out for it. I’ll probably follow that up with something RedHat focused as that seems to come up quite often in comments and emails. Beyond that I’d like to start working on a really small footprint distro (50MB or less if it’s possible) and the required PXE infrastructure for booting it. My schedule is going to be busy through late February so it’s hard to know when I’ll make serious progress on these efforts but just keep checking back for updates – they’ll get here eventually.

Lastly, I know in my previous post for creating an Ubuntu live CD I was asked, and then posted, the ISO I created for the tutorial. I am certain people – busy people, of course – will ask for me to post the tar.gz file I created for this tutorial as well. Unfortunately in this case, I am not 100% certain I have the rights to redistribute the VMware View Client in a way inconsistent with it’s released packaging. Being a VMware employee means I need to be really sure before doing something like that. So for now, I will not be posting a direct link to the extracted client bits – I’ll sell you the bullets, but I won’t hold the gun and pull the trigger for you, if you will. Honestly this is a pretty straightforward process, and my belief is that it’s always better to teach people to fish – so get fishing people!

With the recent public release of a full PCoIP View client for Linux I imagine many people will look to use this as a low-cost platform for re-purposing PCs as a lightweight View endpoint.

As the VMware View Client for Linux is only (officially) available for Ubuntu right now I will focus on that. Consider this the first part of an ongoing series, but right now I’m just going to cover the basics of getting an image setup so that you can live boot Ubuntu and have the View Client installed in the image.

 

Getting Started

Before we do anything you are going to need to grab Ubuntu 11.10 (http://www.ubuntu.com/download/ubuntu/download). I will be using the 32-bit version for this walk-through.

I also will be doing the creation and testing of the live CD from a virtual machine and I highly recommend you do the same. I am using my home lab with vSphere 5, so I’ll be using vCenter to create a new VM, but any virtualization platform can be used.

The virtual machine we’re creating here will be our live CD “build” machine, there’s nothing special about it, it’s just a straight installation of Ubuntu, so let’s get on with it. First, create a new VM, select “Typical”, give it a name and location, select resource pools, and select storage placement – I assume the audience for this blog is quite familiar with this process, so I will skip detailed instructions. When prompted for “Guest Operating System”, select Linux, and under “Version” select Ubuntu Linux (32-bit).

Complete the final steps of the New Virtual Machine Wizard – I created a 30GB disk which is likely overkill – and create the VM. I did make some changes to the hardware settings – I bumped up to 2GB RAM and added a second CPU. This is not required, it just made me feel good.

Once the VM is created mount the Ubuntu ISO file into it via whatever your preferred method is. I uploaded the ISO to a datastore, and mapped it into the VM from there. If you use this method make sure to select “Connected” and “Connect at power on” – and then to deselect these options after the installation process is complete.

Access the console for the VM, and power it on. Shortly after it boots  you will be presented with the following screen, select “Install Ubuntu”

Again, I am going to skim the details of OS installation as I assume my audience is familiar with the process:

• I selected “Download updates while installing”
• I allowed the installer to use the whole disk and took the default file system layout (2 partitions)
• Select your location and language preferences
• Enter your user account information, and select “Log in automatically”
• Let the installation complete
• When prompted to restart, click “Restart Now”. You should then be prompted to remove the installation media per the image below
• Disconnect the ISO image from the VM, go back into the console, and press ‘Enter’ to complete the shutdown

A brief introduction video is up. I wanted to keep this first video at a pretty high level, just introduce the tool and give a glimpse of it in operation. Future videos will go into detail on specific functions and how to do data analysis.