WilliamLam.com

Search Results for: kickstart

Potential ESX(i) 4.1 Update 1 upgrade caveat

by // Leave a Comment

If you are planing on upgrading to the recent release of ESX(i) 4.1 Update 1 from ESX(i) 4.1, you may want to verify that you will not be impacted by a previous security/password bug found in ESX(i)4.1. The security bug that was identified with ESX(i) 4.1 was the encryption algorithm which changed from default MD5 as previous releases of ESX(i) to legacy DES.

This bug has since been resolved and a VMware KB article (KB1024500) was released with a temporary fix by adding the keyword "md5" to system-auth PAM configuration entry. This fix also required the user to update the root password afterwards, as the previous password was encrypted using DES.

The potential caveat is if you did not apply the fix as mentioned from the above VMware KB article prior to upgrade, after the ESX(i) 4.1 Update 1 upgrade, you will continue to run into the same problem. The fix is to reset your root password after the upgrade of ESX(i) 4.1 Update 1, this will ensure that the new password will be encrypted using the MD5 algorithm. Though the fix is simple, it can be tedious and manual for users who do not regularly rotate their root passwords or have an automated password management system.

To check whether this will impact your upgrade, login to ESXi Tech Support Mode or classic ESX Service Console and check whether the root password was encrypted using MD5 or DES. To do so, you will cat out the contents of /etc/shadow

If the root password was encrypted using MD5 algorithm, you should see root hash start with "$1$"

If the root password was encrypted using DES algorithm, the root hash will not start with "$1$"

If it is the latter, you will need to either apply the fix and update the root password before upgrading or reset the password after your upgrade. To change the root password, you need to login to either the Serivce Console for ESX or Tech Support Mode for ESXi and run the passwd utility to change your password.

It is probably quicker to rebuild than to login to each host an update the root password, especially if you have an automated kickstart environment. This will ensure that that all hosts will be consistent and no manual fixes will be required. IMHO, this is something that VMware should have clearly pointed out in their release notes as not everyone may be aware of the VMware KB article and implemented the fix prior to upgrade.

Another way to enable management traffic on ESXi

by // 3 Comments

Here is another way in you can enable the management traffic type on a VMkernel interface in ESXi without having to resort to using the vSphere API, this especially useful when automating a kickstart installation.

When you enable a specific vmkX interface (esxcfg-vmknic -l) to allow for the management traffic type, there is an entry that is made in the /etc/vmware/hostd/hostsvc.xml file. The specific interface is denoted by a unique nic id which starts off at 0000 and is incremented by one for additional VMkernel interfaces that are added.

If you add a second VMkernel interface called vmk1 and you wanted to also enable it for management traffic, the file would look like the following:

For the changes to take effect, you will need to restart hostd agent by running /etc/init.d/hostd restart. You will also need refresh the network sub-system by using vim-cmd hostsvc/net/refresh which will refresh the vSphere Client view else you will have to do it manually before you can see the update.

This is probably overkill, but I decided to write a simple script in which you can pass the VMkernel interface name and the script will update hostsvc.xml file with the proper nic id/etc. Here is an example for enabling management traffic for vmk1:

Download: enableMgmt.sh

If you would like to integrate this into your ESXi kickstart, you can easily do so based on the number of VMkernel interfaces you will be creating during the installation. You can add the following into your %post section which uses a here document to overwrite the existing hostsvc.xml with the expected VMkernel interfaces that should have the management traffic type enabled.

HOSTSVC_FILE=/etc/vmware/hostd/hostsvc.xml

cat > ${HOSTSVC_FILE} << __CREATE_HOST_SVC__

  
    vmk0
    vmk1
    vmk2
  
  normal
  
    on
    on
    on
  

__CREATE_HOST_SVC__

This is a cleaner alternative than using python and connecting to the vSphere API locally on an ESXi host which is described in my blog article Automating ESXi 4.1 Kickstart Tips & Tricks Tip #7

Ghetto Reflections 2010

by // 1 Comment

Looking back on 2010, it is hard to believe that virtuallyGhetto was created only 7 months ago. Instead of writing a long post, we thought we would share with you some of the highlights and favorite blog posts/scripts of 2010:

Here were the highlights for virtuallyGhetto in 2010:
May 31st - virtuallyGhetto says hello to the blogosphere
June 25th - virtuallyGhetto is part of the esteemed VMware Planet v12n feed
Sept 27th - virtuallyGhetto made the Top 25 VMware Bloggers List
Nov 19th - Veeam becomes first sponsor for virtuallyGhetto

Here were the top 10 blog posts of 2010 by page views:
Automating ESXi 4.1 Kickstart Tips & Tricks 9,914
ESXi 4.1 - Major Security Issue 4,564
Getting started with vMA 2,976
What is VMware vsish? 2,768
1200+ undocumented .vmx parameters 1,660
Automating vCloud Director and Oracle DB Installation 1,283
Script: Updated ghettoVCB and ghettoVCBg2 to Support vSphere 4.1 1,279
vMA 4.1 - Active Directory IntegrationTip 1,240
How to inject custom drivers into an ESXi 4.1 image using vibddi? 1,239
How to configure and use vMA's vi-fastpass with fpauth and adauth on vSphere 4.1 1,121

 

Here were the top 10 ghetto scripts of 2010 by page views:
ghettoVCB.sh 367,905
ghettoVCBg2.pl 66,683
vmwarevSphereHealthCheck.pl 62,861
ghettoShutdown.pl/upsVIShutdown.pl (DEPRECATED) 48,693
vmwareHealthCheck.pl 36,969
ghettoVCB-restore.sh 30,583
ghetto-esxi-linked-clones.sh 12,227
ghettoUPSHostShutdown.pl 7,820
vmwarevSphereSecurityHardeningReportCheck.pl 5,356
ghettoHostBackupManagement.pl 4,723

*Note: You may have noticed that the ghettoVCB VMTN document is currently inaccessible (displays "Forbidden" error). This is a known issue that was caused by the recent VMTN community upgrade by VMware. We apologize for any inconvenience this may have caused and we are hoping the issue will get resolved when VMware resumes after the holiday period. In the meanwhile, you can access the document via Google cache for the latest version of the script*

We also want to take this moment to thank our readers and the virtualization community for the support that you guys have given us through the comments on the blog, VMTN, linkage, twitter re-tweets, etc. There are two individuals that I would like to personally thank: Duncan Epping who has encouraged me on numerous occasions to start my own blog. In the end, it was the passion and dedication that Duncan put into his own blog to share with the community that really inspired me to start virtuallyGhetto. I would also like to thank Chris Wolf, who has been one of our first avid supporters of ghettoVCB and even today, he is still one of our largest advocate, providing honorable mentions even in his VMworld presentations!

We look forward to 2011 and hope to continue to provide great content and scripts to the VMware and virtualization community. We wish you happy holidays and a great New Year! See you all in 2011!