Friday, January 13, 2012

VMware ESXi 4.1 critical and security update via command line utility

VMware ESXi provides outstanding environment for virtualization and it's free. Free may means extra work required to maintain this environment with update issues.

To search for any patch available, please visit:
http://www.vmware.com/patchmgr/findPatch.portal

Correctly quote the product and the version for your existing environment and you will find useful patches for use.

Download the required patches and make sure VMware vSphere CLI package has been installed properly so you can open up Terminal/Command Prompt to run its perl script tasks. Assuming you are working on Windows desktop, you may find the following paths after CLI installation:

Embedded Perl:
C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl.exe

vSphere CLI included its own Perl package for operation. It is important to quote absolute path of correct perl program so those required Perl modules are involved during the tasks.

Perl scripting tasks location:
C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\*.pl

Before the scripting task is carried on the ESXi host, it is necessary to shut down all guest VMs and then put ESXi host in maintenance mode. These can be done via VMware vSphere Client. Install this if you don't have one. The latest free edition is VMware vSphere v4.

The following Perl script commands will be required to run specific tasks:


#

#Put ESXi host in maintenance mode



#Check ESXi host information

>"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl.exe" vihostupdate.pl --server IP_ADDRESS_ESXi_HOST -operation info



#Make a query on any patch installed on ESXi host

>"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl.exe" vihostupdate.pl --server IP_ADDRESS_ESXi_HOST --query



#List all updates available in the downloaded patch package

>"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl.exe" vihostupdate.pl --server IP_ADDRESS_ESXi_HOST --list --bundle "C:\temp\update-from-esxi4.1-4.1_update02.zip"



#Compare and see which patch bulletin applicable to ESXi host

>"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl.exe" vihostupdate.pl --server IP_ADDRESS_ESXi_HOST --scan --bundle "C:\temp\update-from-esxi4.1-4.1_update02.zip"



#Perform actual installation of patch with bulletin specified

>"C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin\perl.exe" vihostupdate.pl --server IP_ADDRESS_ESXi_HOST --install --bundle "C:\temp\update-from-esxi4.1-4.1_update02.zip" --bulletin ESXi410-Update02



#Once completed, reboot ESXi host and put it back to operation mode, start guest VMs for testing








Monday, January 9, 2012

Remotely unlocking LUKS encrypted root partition via SSH

It has been a while since famous DropBear script invented and became Ubuntu package for streamlining the unlocking mechanism of encrypted partition remotely from client computer.

Recently, an inspiring article has been found for a practical approach to this special feature. Of course, it might involve some manual operations during the server reboots and wait for your input to unlock it.

A working solution tested on Ubuntu 9.10 Karmic Koala:

Assuming you have an Ubuntu machine with fully encrypted partition, and you would like to unlock this partition during the boot-up but you are not sitting there in front of the machine. Definitely, you can do it somewhere with another computer.

On Ubuntu machine:

To setup Dropbear SSH Server:
$

$ sudo apt-get install dropbear busybox


Please remind that the package like early-ssh is not required in this case and it is assumed that a working OpenSSH server has been installed and running properly.

Latest version like Ubuntu 11.04 might have problems with the original dropbear script and requires manual modification. It is recommended to refer to  this link for more information.

Now update INITRAMFS:
$

$ update-initramfs -u

It's time to enable the root account in Ubuntu whereas only root user can login Dropbear SSH Server successfully.
$

$ sudo passwd root



You must take extra precaution while enabling root account can lead to security issue on your OpenSSH service. It is recommended to disable root login for OpenSSH by changing the following lines in /etc/ssh/sshd_config.
# change in /etc/ssh/sshd_config

PermitRootLogin no

This is useful in preventing the outsider trying to login as root.

Within the timeframe of DropBear SSH session, the root account is effective anyway. After the unlock operation is finished, DropBear will let the regular OpenSSH server to take over and retires gracefully. Therefore, you may expect DropBear session to be disconnected after you enter correct passphrase to unlock the partition. Then you will need to login again with its OpenSSH session instead.

Before restarting the machine, it is necessary to copy the private key out of Dropbear SSH Server.
A reference command would be like this (assuming you use Linux client to connect to Ubuntu machine):
#Use SCP to copy a certificate from remote machine to local Linux machine
scp user@remote.server:/etc/initramfs-tools/root/.ssh/id_rsa ~/.ssh/remote_dropbear_id_rsa


If you are using Windows client, then you can download WinSCP to copy the file directly onto your desktop. You might notice that an error occurs while you are copying due to file permission. This means you need to set a proper file permission of id_rsa on Ubuntu machine before you copy it out.

After that, reboot your Ubuntu machine and wait for the prompt of passphrase. However, Dropbear SSH Server will also loaded up behind the scene and wait for the authenticated client to enter passphrase remotely. Who is the authenticated client? That might be the one holding the private key generated by Ubuntu machine.

On Client computer:

Assuming you use Windows client to connect and you will need two pieces of software to make it work
Putty.exe
Puttygen.exe

Basically, comprehensive package of Putty includes both of these executables once you download and install its Windows installer from here.

Native Linux generated private key needs to be converted to .PPK file for import in Putty client. That's why we need Puttygen.exe. For instructions, please refer to this link under the section of "Converting the OpenSSH private key to Putty format". To login remotely with the converted private key, please refer to the section of "Logging in Openssh using id_rsa.ppk".

When Ubuntu machine is rebooted and pending for passphrase input, you can login from the client computer remotely with Putty.exe with a proper private key. Bear in mind that you need to login as root user into DropBear SSH console.

Once you login successfully to Dropbear console, you can enter the passphrase from there with a script command:
$

$ echo -ne "**encryptionpassphrase**" > /lib/cryptsetup/passfifo


whereas **encryptionpassphrase** is the required passphrase to unlock the encrypted partition.

You may not notice anything over the console. If the passphrase matches, Ubuntu machine will unlock the disk partition and start to load up at the other side. You can close Dropbear console and then login again into the OpenSSH console of Ubuntu machine with you regular user account from the client computer.

Note: An issue has been experienced regarding IP address distributed by DHCP server. To prevent a different IP address allocated to Ubuntu machine after reboot. It is necessary to setup static IP configuration to make sure IP address unchanged even after Dropbear SSH server loads up. Please refer to this link for more information.




















Friday, January 6, 2012

Merge VMWare snapshot with base VM to reduce size of vmdk

One server is hosting VM Server v2.x and has been reverted to a previous snapshot after crash. Within the host, the files snapshot vmdk and base vmdk now co-exist even after I remove the snapshot by GUI menu item. The file size of vmdk files is huge and almost a double of the current disk size on guest VM.

To merge and reduce the size for those vmdk files, a piece of freeware VMware Convertor does really help! By converting a new VM from existing VM, multiple .vmdk files have been merged and reduced in size in the destination folder. Now, it becomes one single .vmdk file with smaller size.

Before the conversion, the guest VM must be shutdown completely. After all, you will get a .vmx and a .vmdk file in a smaller size.

Furthermore, you may want to actually shrink the disk within Guest VM. This is possible if you have installed latest version of VMware tools inside Guest VM.


Shrinking a disk is a two-step process:

In the first step, called wiping, VMware Tools reclaims all unused portions of disk partitions (such as deleted files) and prepares them for shrinking. Wiping takes place in the guest operating system.

The second step is the shrinking process itself, which takes place on the host. Workstation reduces the size of the disk's files by the amount of disk space reclaimed in the wipe process.


For the first step, follow the below instructions inside running target Guest VM:


1. Launch the vmware-toolbox.

Windows guest — double-click the VMware Tools icon in the system tray, or choose Start > Settings > Control Panel, then double-click VMware Tools.
Linux or FreeBSD guest — become root (su -), then run vmware-toolbox.

2. Click the Shrink tab.

3. Select the virtual disks you want to shrink, then click Prepare to Shrink.

A dialog box tracks the progress of the wiping process.

Note: If you deselect some partitions, the whole disk is still shrunk. However, those partitions are not wiped for shrinking, and the shrink process does not reduce the size of the virtual disk as much as it could with all partitions selected.

4. Click Yes when VMware Tools finishes wiping the selected disk partitions.

A dialog box tracks the progress of the shrinking process. Shrinking disks may take considerable time.

5. Click OK to finish.

For the second step, you are ready to issue a command at the terminal on Host machine:

Assuming Host machine is running Windows, you can issue a command like this (change target vmdk path accordingly).

"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager.exe" -k  "\*destination*\target.vmdk"


Reference: http://www.vmware.com/support/ws5/doc/ws_disk_shrink.html