6 Replies Latest reply on Apr 9, 2011 12:30 AM by lamw

    A few oddities with the check script

    Sean D Novice

      I just tried the latest (1.7) version of the check script and found a few oddities I wanted to report.

       

      For all of this I'm using vCLI 4.1 on linux, connecting to ESX 4.0u2 and vCenter 4.0u2.

       

      1) The vCenter check for VUM running on a different server doesn't seem to work.  In my test environment, vCenter and VUM are on the same host, yet the test passes.

       

       

      2) When I run the host checks against one of my boxes, I receive a bunch of errors:  http://pastebin.com/zXSL5LAK   Any idea how to fix these?

       

       

      3) The smtp headers seem a little busted with the new MIME stuff.  I'm seeing a subject line like:

       

      Subject: VMware vSphere Security Hardening Guide Check Completed\nMIME-Version: 1.0
      
      
        • 1. Re: A few oddities with the check script
          lamw Guru
          Community WarriorsVMware Employees

          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:

           

          https://[server]/host/proxy.xml

          https://[server]/host/ssl_cert

          https://[server]/host/syslog.conf

           

          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

          • 2. Re: A few oddities with the check script
            dconvery Virtuoso
            vExpert

            Will -

             

            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?

            • 3. Re: A few oddities with the check script
              lamw Guru
              VMware EmployeesCommunity Warriors

              Dave,

               

              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.

              • 4. Re: A few oddities with the check script
                Sean D Novice

                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.

                • 5. Re: A few oddities with the check script
                  lamw Guru
                  Community WarriorsVMware Employees

                  Sean,

                   

                  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