WilliamLam.com

Search Results for: content library

How to compile Busybox for ESXi ... kind of Part 2

by // Leave a Comment

Continuing from part1 of How to compile Busybox for ESXi ... kind of Part 1 we found some challenges in compiling VMware's Busybox version found in ESXi OSS Source Code. In this article, we will go through process of compiling the latest version of Busybox which is currently 1.18.3 to run on ESXi.

Again, before getting started, a word of caution:
!!!! THIS IS NOT SUPPORTED BY VMWARE - PLEASE USE AT YOUR OWN RISK !!!! 

The build environment that I used is running the latest version of CentOS 5.5 64bit which can be downloaded here.

Step 1

Download busybox-1.18.3.tar.bz2 from the Busybox's website and SCP it to your build system.

Step 2

You will also need to install the following packages, you can do so using yum if you are using CentOS or RHEL and have a proper repository configured. You can use the following:

yum install -y gcc flex bison texinfo ncurses-devel libselinux-devel.x86_64 pam-devel.x86_64

Step 3

Extract the contents of busybox-1.18.3.tar.bz2 using the following command:

tar -xvjpf busybox-1.18.3.tar.bz2

Step 4

You will now change into the busybox-1.18.3 directory and from here you have a few ways of building Busybox. To get a list of build options, use the following command:
make help

You can customize the build of Busybox by enabling and disable specific applets to be compiled. If you want to build Busybox with no applets (not really useful), you can run the following command:

make allnoconfig
make

Once the compilation is complete, you will now have a Busybox binary in which you can run but it does nothing useful:

You can also perform the exact opposite by enabling all options which can be called using the "allnoconfig" or "defconfig", you can run the following command:

make defconfig
make

Once the compilation is complete, you now have Busybox binary which has all the available applets by default:

Enabling all applets, the Busybox binary still comes out to be less than 900k. If you wanted to create a custom Busybox with specific applets, you can manually edit the .config file which is where the features are either enabled or disabled. This can get very tedious, luckily there is a make option which allows for an interactive menu on selecting the applets you would like to include in the build.

Step 5

To enable the interactive menu, you will run the following command:

make menuconfig

From here, you will be able to configure the Busybox settings and the various applet types by their functions such as networking or mail utilities. One feature that is actually disabled in the VMware's version of Busybox is the support for large files, if you tried to tar up a file that was larger than 2GB and then extract the file, you will notice you get an error regarding the file size. The reason is VMware decided to not enable this feature in their Busybox build.

Step 6

Once you are done selecting or de-selecting all your Busybox settings and applets, you will need to save your configuration which is stored in the .config.

Step 7

Once you have exited from the interactive Busybox menu, you are now ready to build your custom version of Busybox, you will run the following command:

make

Step 8

If everything went well, you now should have a busybox binary in your current working directory. Here is an example of my custom Busybox image:

If you would like to customize the version information found when just running busybox command without any arguments, you can edit the Makefile and append your custom text to EXTRAVERSION variable.

Now you just need to re-run the "make" command and your new busybox binary will include the additional version information.

Now before you jump and start creating your own Busybox binary, I must throw in another caveat that re-iterates the title of this post. Just because you have Busybox built with all these applets, it does not mean it will run 100% on ESXi, the reason being is there are specific dependencies that the non-VMware Busybox applets may rely on which are just not available with ESXi. This is one of the reasons why VMware did not just enable all applets from Busybox to begin with, your mileage will vary depending on the particular command you have enabled.

Here is an example of my custom Busybox applet "crontab" using the "-l" flag which lists any active cron entries for the particular user:

It runs just fine on ESXi as you can see, but let's try using the "-e" flag which if you are familiar with using crontab you will know that is the option to edit your cron entries:

Ooops, what's this? It looks like this particular operation of crontab relies on vfork which is not implemented. I have seen other similar errors with other applets relying on particular dependencies in the environment that just does not exist with ESXi. I have not tested every single applet and some may work 100% while others may be partially functional, you will need to test and verify for yourself.

If you feel adventurous, go ahead and download Busybox and start playing with it. I would highly recommend that you test this in your vSphere development environment before trying this on a production host. I would also recommend that you do NOT replace the default Busybox binary found on ESX(i) as you can run into some serious issues. Since the Busybox binary is self-contained, you can store it in /tmp or somewhere more permanent such as a local or remote VMFS datastore and renaming the file will also remove any confusion.

If you find other utilities that you feel that should be included in the default Busybox applet and do not want to resort to something like Poor man's traceroute for ESXi, be sure to submit your feedback to either your VMware rep or file a feature request.

If you are interesting to learning more about Busybox, check out their FAQ page and this page for more details.

Again, another warning:
!!!! THIS IS NOT SUPPORTED BY VMWARE - PLEASE USE AT YOUR OWN RISK !!!!

How to backup VMs in ESX onto Dropbox

by // 5 Comments

I previously wrote about backing up virtual machines directly from ESX and ESXi onto both Amazon S3 and Google Storage, but there was actually a third online file hosting company that I wanted to get working, Dropbox. Dropbox is a relatively new file hosting company that launched back in 2008 and has gain popularity for its ease of use and ability to access and share files across multiple devices. While researching Dropbox initially, I discovered there was a python-based CLI which I was hoping would install and function on ESX(i). This unfortunately did not pan out due to the various python library dependencies including a newer version of python.

While scouring the web, I recently found out that Dropbox actually released a Linux client binary and I thought I'd kick the tires and see if I could get it running on ESX(i). After a few minutes of testing, I found out that it was possible to get it running on classic ESX, but there are still certain python dependencies that prevent the Dropbox client to run on ESXi.

Before you begin, you will need to sign up for a free Dropbox account. With the free account you automatically get 2GB of free online storage, if you want more, you can pay for up to 100GB of online storage. The following has been validated on ESX 4.1, I have not tested this on any other ESX version and your results may vary. ESXi is not supported as mentioned earlier.

1. Download the latest Dropbox Linux Client here.

2. You will need to upload the Dropbox tar ball to your ESX host, you can use scp on UNIX/Linux or winSCP if you are using a Windows system.

3. You should not have the tar ball file sitting in the root directory of your ESX host:

4. You will now need to extract the contents of the tar ball, by running the following:

tar -zxvf dropbox-lnx.x86_64-0.7.110.tar.gz

5. You should now have a hidden directory called .dropbox-dist in your current working directory:

6. If you are starting the Dropbox client for the first time, it will default to using home directory of the current user to access your Dropbox share. In our case, it will be stored as /root/Dropbox which is probably not what you want. We will actually update our home directory to point to a VMFS volume path, by setting the HOME environmental variable:

As you can see, now our new home directory is set to a VMFS datstore. Once the Dropbox client starts, it will create a 64bit encoded string of the path which is stored in a configuration file once you have authorized the addition of this system to your Dropbox account.

Note: Once the default Dropbox path is set, you need to ensure that environmental HOME dir is always set to the one you specified above, else when you start Dropbox it will think it is a new setup.

7. We will now start the Dropbox daemon and ensure that we run it in the background:

If you have successfully started the Dropbox daemon, a unique URL will be generated based on your system which is used to authorize this system to access your Dropbox account. Take the URL and paste it into a browser, it should ask you to login to authorize the system.

8. If this is the first time you are using Dropbox, once you have signed in, you will be brought to the files tab in which all the folders and files that are currently accessible to you. By default, you will have a Public and Photos folder in which both are empty:

9. If you go back to your ESX host, you will now notice some output regarding nautils, you can ignore this error as the packages are not required for functionality:

10. Now, if you remember when we set the home directory to trick Dropbox to put folders under a VMFS datastore, you will now see a new directory called Dropbox which will contain the Public and Photos folder you saw on your web browser:

11. For demo purposes, I created a Backup directory in Dropbox root folder on the ESX host which will be visible from your web browser:

I then created a dummy 1MB VMDK in the same folder as if you were copying a VM to Dropbox account:

You can now go back to your web browser and see the VMDK file that was just created in the Backup directory:

There you have it, you can now transfer files or backup your virtual machines from your ESX host to your Dropbox account.

Earlier I mentioned that there are configuration files that tells the Dropbox client that this system is authorized to connect to your Dropbox account and it stores both the system ID along with the Dropbox path. If you do a long listing in your VMFS volume that was used to store your Dropbox folder, you will notice a hidden directory called .dropbox:

There are two database files, dropbox.db that contains the files and folder structures as it is being synced down to the host and host.db which contains the system's ID and Dropbox path which is encoded as 64bit string. You can decode and verify the path by using this website: http://webnet77.com/cgi-bin/helpers/base-64.pl

Here is what the host.db file looks like:

The second line contains the Dropbox path and you should not try to edit this file manually as it may cause synchronization issues. If you look at the Dropbox documentation, there is a python script that allows you to change the path but it requires sqlite3 to be available which is not available by default on ESX.

Why you should upgrade from vMA 4.0 to vMA 4.1

by // 5 Comments

As you may know, with the release of vSphere 4.1, core vSphere components such as vCenter and ESX(i) all received significant feature updates. This was no exception with VMware vMA, though the number of updates were minimal but still signifcant.

Here is the list of new features:

  • Support for Windows Active Directory Integration using Likewise Open
  • Offline bundle support for upgrading vMA
  • Resolved major security flaw with vi-fastpass component

1. Support for Windows Active Directory Integration using Likewise Open
For those that use Active Directory, you now have the capability of centralizing your user management on vMA. Using Likewise's Open software, users can now login to vMA using their AD credentials. Not only can they login, but with the enhancement of the new vi-fastpass, you can now add a target and configure it to support AD authentication versus normal fastpass authentication. This means that the user who logs into vCenter can log into vMA to perform an operation such as adding a vSwitch or powering on a Virtual Machine without providing further credentials using this new AD authentication passthrough. For more details, take a look at this article vMA 4.1 Authentication Policy - fpauth vs adauth.

2. Offline bundle support for upgrading vMA
Prior to vMA 4.1, to upgrade the software within vMA, you had to use vima-update (now renamed to vma-update) which connects to VMware's online repository. This was an issue for envrionments that did not have direct internet or proxy access to VMware's website and there were no supported work arounds for this. You now can download an offline bundle just like you can for  ESX or ESXi and perform an offline upgrade.

3. Resolved major security flaw with vi-fastpass component
Saving the best for last. This has been a security issue that has existed since the release of VIMA 1.0 which was not considered an offiical release by VMware until vMA 4.0. The issue was with the use of vifpinit (now renamed to vifptarget) and when a target was initialized using the vi-fastpass library, the username and password was viewable in plain text.

When you add a target to vMA's management using vi-fastpass, two accounts are created on the target host: vi-adminXX and vi-userXX. The password for these two accounts are obfuscated using a simple XOR cipher which can be cracked in days if not hours and the obfuscated form is stored in a credential store located in /home/vi-admin/.vmware/credstore. Prior to vMA 4.1, when you initialize a target from this credential store, you are allowed to execute any vCLI or vSphere SDK for Perl script without having to provide additional credentials to the host. The authentication is basically bypassed as it uses the vi-adminXX credentials to login and perform the operation. The side effect of initializing the fastpass target, was that the password to the vi-adminXX was exposed as plain text via an environmental variable.

Here is an example of of initializing a target on vMA 4.0 with the password exposed:

As you can see from above, both the username and password is exposed as a simple environmental variable entry. You can now take those credentials and login to an ESX(i) host and perform an administrative operation as if you were root.

Here is an example of using these credentials to create a new vSwitch on an ESX host:

Before you jump and upgrade vMA 4.1, note that the security issue has been resolved but it does NOT make the system any more secure than it was in vMA 4.0. The vi-fastpass is actually available as a library module that supports both Perl and Java. There is available sample code under /opt/vmware/vima/samples/ for vMA4.0 and /opt/vmware/vma/samples/ for vMA 4.1. Using this library, you can access the targets under vMA management which also includes both the username and password in its unencrypted form.

Here is a vMA 4.0 script I wrote called enumeratevifp40.pl that demonstrates the above:

Here is a vMA 4.1 script I wrote called enumeratevifp41.pl that demonstrates the above:

As you can see, even with the security issue fixed vMA 4.1, a user can still access the entire credential store and obtain both the username and password to any of the targets. The only real way to protect against this issue is to use adauth when adding your targets and forcing users to authenticate against your AD server when connecting and performing an operation on vCenter or an ESX(i) host. For those that must use standard fpauth, VMware has released a KB1017669 article for vMA 4.1 on securing the credential store by creating an encrypted volume in which the obfuscated file is stored in. This ensures that if you are transferring your vMA image, someone can not just mount the VMDK and extract the credential store file and try to decrypt the contents.

Now, that you understand the security implication and features available with vMA 4.1, off you go to upgrade 🙂

Here are additional links that may also be useful: