Sean, thanks for the feedback.
1) The way I'm verifying VUM is by looking at a particular port, 9087 thinking this would only be enabled if VUM was running locally, perhaps this is incorrect. Since VUM does not have a native API that I can hook into, I'm using inferences based on this fact but it may be incorrect. I may have to look into another way to validate that VUM is in fact not running on the same host as vCenter, else this will turn into a "manual" check. Let me know if you thoughts/ideas around this
2. The first few lines deals the actual logging mechanism, so it doesn't really tell me which check is causing an uniti value. What I do notice in the subsequent section of errors is related to downloading a few of the local files from the ESX(i) hosts.
In particular, it's performing a GET operation on the following URLS:
The script also assumes you're using vMA, which is one of the called out requirements as it expects certain things on the system such as openssl if you don't already have that as a default. Technically speaking, as long as you're running this on a UNIX/Linux system with vSphere SDK for Perl, everything should work fine. See if you can manually perform a wget on those files? If not, that maybe an issue as it needs to somehow pull those files down to verify some of the checks
3. Looks like an issue with the quotes, I've just pushed the change in 1.8, take a look here for the updated version (Will update the main script in the VMTN doc, once issues have been resolved) - http://vghetto.svn.sourceforge.net/viewvc/vghetto/scripts/vmwarevSphereSecurityHardeningReportCheck.pl?view=log
It may not be a good idea to check for the presence of port 9087 since it most likely can be changed. How about checking for the running service?
Yea, I think when I wrote the VUM sections, it was my first attempt and didn't really revisit the problem or heard of issues. I'll have to re-investigate this to see if it's possible to verify whether it's running on the same host as vCenter.
1) Ah, we have firewalls in place, thus the problem. If you check ExtensionManager, there should be an extension with the key "com.vmware.vcIntegrity" for VUM. Several of the properties off of there include VUM urls. You can grab the hostname from one of those and resolve it to an IP. Then you can take the vCenter's hostname, resolve it to an IP and compare. We configure our vCenter to think of itself as a CNAME and vum tends to present the underlying hostname, which is why I suggest resolving to IP.
2) I see the issue now. My .visdkrc is configured to use a read-only account by default, so I don't accidently break anything. It looks like read-only is not enough to download those files. My full normal account seems to do better.
Great idea! I should have thought about that, funny thing is my vSphere Health Script actually goes through and figures out what VMware apps run in the infra and this totally did not cross my mind. I think this is definitely a much better way to check whether VUM is on the same host as vCenter. I'll post an update once I have the code in place