WilliamLam.com

Automating Active Directory Domain Join in ESX(i) Kickstart

by // 10 Comments

I recently received an email asking if it was possible to automate the joining of an ESXi 4.1 host to Active Directory within a kickstart installation. The simple answer is yes; you can easily do so using the same trick found in tip #7 in Automating ESXi 4.1 Kickstart Tips & Tricks post which connects locally to the vSphere MOB using python.

Having said that, there is a small caveat to this solution in which the credentials used to join the ESX(i) host must be exposed in clear-text, this may or may not be acceptable. A potential way of getting this to work is to create a dedicated windows service account with limited privileges to add only ESXi hosts to your domain.

The reason for the use of clear-text password is the vSphere API method that is used to join an ESX(i) host to AD domain, joinDomain(), only supports plain text.

[Read more...]

How to compile a statically linked rsync binary for ESXi

by // 36 Comments

Running rsync on ESXi is not a new topic, there are a number of users in the community who have made this work. One well-known user, Dave Mishchenko, who runs vm-help and recently authored VMware ESXi: Planning, Implementation, and Security, provides an rsync binary that can be downloaded to run on ESXi. Not that I did not trust Dave and the source of his rsync binary, but I wanted to compile my own and understand the process Dave took to get to a compatible rsync for ESXi. In talking to Dave, I found out the binary was actually provided by a VMTN user, named glim who had noted some of the details in this VMTN thread.

The user basically created a statically linked versus a dynamically linked version of rsync which runs without relying on libraries that may or may not be present on ESXi. My initial attempts failed using both a 32/64bit CentOS 5.5 and latest version of rsync 3.0.7 and 3.0.3. The compilation of rsync was successful, but upon executing on ESXi, it immediately had a segmentation fault. I started to think there might be some dependencies in libraries that were used to compile rsync that I was missing. I was also in conversation with Alain Spineux, creator of MKSBackup regarding this same topic and he had found a way to compile rsync based on the article Hacking ESXi by Stjepan Groš.

Stejepan found that using CentOS 3.9, one could compile both statically and dynamically linked binaries without any modifications to ESXi. Though Stejepan did not provide the steps to compile rsync, it is relatively simple to do so. I also found that you do not need to use older 3.0.3 release of rsync, you can use the latest version which is 3.0.7 as of writing this article.

Before we get started, let me remind you of the disclaimer:
*** THIS IS PROBABLY NOT SUPPORTED BY VMWARE, USE AT YOUR OWN RISK ***

Step 1

Download and install CentOS 3.9 i386 - You can find a list of download sites here

Step 2

With a default installation of CentOS 3.9, you just need to get GCC installed

yum -y install gcc

Step 3

Next you will need to download the latest version of rsync which is 3.0.7 here and SCP it to your CentOS system

Step 4

Next you will now extract the contents of the rsync-3.0.7.tar.gz

tar -zxvf rsync-3.0.7.tar.gz

Step 5

Now you will change into the rsync-3.0.7 directory and run the configure command

./configure

Step 6

Now you will run the make command which will compile rsync, but you will also be passing in additional flags to create a statically linked binary

make CFLAGS="-static" EXEEXT="-static"

Step 7

Finally, you will need to run the strip utility which discards all symbols from object files

strip rsync-static

You now have a self-contain rsync binary labeled rsync-static found in the current working directory

Next up, you will SCP the rsync-static binary to your ESX(i) host and set the appropriate permissions to execute. I decided to temporarily store it in /tmp, but if you want the binary to persist through a reboot, you may want to store it in either a local or remote VMFS/NFS volume.

I quickly verified that rsync was in functional, by rsyncing /etc directory in ESXi over to another host. I use the following command:

/tmp/rsync-static --compress --progress --stats -e dbclient -Rr /etc build-centos:/upload

Once the file transfer has completed, you should see the /etc directory replicated on the destination host.

You may have noticed in the command line we are specifying "dbclient", by default rsync will go over SSH but ESXi does not actually have the traditional ssh client that we are all used to. It actually uses dropbear which is tiny SSH server and client which is frequently used in embedded systems such as Busybox.

Since /bin/ssh path does not exists, rsync will fail unless you specify the dbclient to the -e parameter.

Alain also found that retrieving peer name may fail and the rsync code currently does not properly handle this failure and just exits. By looking at the clientname.c source code which is part of rsync, Alain noted that even the developers left a comment that states the error could probably be handled without exiting. The fix is to just comment out the rsynerr line which does not force the program to exit when hitting this problem and this can be found on line 171.

Once you have made the changes, you just need to follow the instructions above to compile your static rsync binary. This is not necessary required, but if you run into this issue, this is a quick hack that can help.

I would like to thank Alain for sharing this tidbit of information

ESXi Lockdown mode does not play nice with vMA

by // 1 Comment

Today on the VMTN community forums, a user identified an interesting side effect when using vMA's vilogger and enabling lockdown mode on an ESXi host. What the user found was the vilogger daemon stopped collecting logs when lockdown mode was enabled for an ESXi host. At first, I thought lockdown mode should have no affect on vilogger, as it only disables the "root" account from accessing ESXi host other than from the DCUI (Directo Console User Interface).

I replicated the setup in my lab using an ESXi host that was being managed by vMA via vi-fastpass (fpauth) and enabled vilogger for this host. I verified log collection was functional before enabling lockdown mode on the ESXi host, right away vilogger stopped collecting logs when lockdown mode was enabled. When using the "vilogger list" command, the status of the ESXi host goes from "collecting" to "No Permission". I found this to be quite odd and verified what the user was describing in his environment.

Next was to take a look at the vilogger logs which is stored in /var/log/vmware/vma/vilogd.log and I found the same "No Permission" error.

I decided to login to the ESXi host and tailed the hostd logs to see what was going on when lockdown mode was being enabled. What I found was pretty surprising to me, there was a task that removed permissions from the vi-adminXX user account, I was pretty sure at this point, the culprit was related to lockdown mode.

I decided to take a look at VMware's documentation to see what the behavior of Lockdown Mode was and the following snippet taken from vSphere's online documentation explains it all:

The text highlighted in red is the key to the issue the user is facing and specifically the very last section where it states:

you cannot run vCLI commands from an administration server, from a script, or from vMA against the host

This meant that not only the root account was locked out, but all other accounts found on the ESXi host whether they are custom from your environment or from auxiliary systems such as VMware vMA, would be completely disabled. What is even more interesting, even read-only accounts would no longer function, they too had to go to vCenter to be re-proxied to specific ESXi host.

This has a few implications for users considering Lockdown Mode:

  1. All scripts including resxtop and user authentication must go through vCenter. If vCenter went down, you have no remote way to access your ESXi host. This also meant that you could not remotely start up vCenter if it was hosted in a virtual machine but rather from DCUI after enabling Local Tech Support Mode
  2. The use of vMA's vilogger is completely useless when Lockdown Mode is enabled for ESXi host. Users may want to consider setting up a traditional syslog server and have the logs forwarded from the ESXi host

IMHO, I don't think Lockdown Mode should crippled the vilogger functionality, the logging is a "Read" operation and I think re-configuring it to "read-only" role should have suffice. I also think that VMware could have done a better job working with the vMA engineers to support this functionality and have some documentation regarding this issue. For now, if you rely on any type of automation that goes directly to an ESXi host and you are thinking about Lockdown mode, you may want to think twice.