13 Replies Latest reply on Aug 21, 2019 2:45 AM by lurims

    Log the vRO FQDN/IP itself

    lurims Enthusiast

      This is silly.  Could not find or never needed to log the vRO FQDN itself.  What is that object that can log the vRO server FQDN or IP it self.  Any idea?

        • 1. Re: Log the vRO FQDN/IP itself
          Amin Masoudifard Expert

          What did you mean exactly? Login with FQDN or NOT ? or IP address and tell me do you talk about connection to vROM from another server ? (for example vCenter Server)

          Please mark my comment as the Correct Answer if this solution resolved your problem
          • 2. Re: Log the vRO FQDN/IP itself
            lurims Enthusiast

            No.  I am talking about logging the same vRO FQDN name where I logged in and running workflows.  For example, I have 30 vROs running a workflow and send an email,  to recognize, which vRO sent that one 30 emails I get, I need to log the vRO FQDN name too.

            • 3. Re: Log the vRO FQDN/IP itself
              Amin Masoudifard Expert

              I think you can do it simply by another commands like netstat (windows) or tcpdump (linux) from your Mail Server that is configured in your workflow as your sender, so after execution of workflow you can check its related connection ... I think so it's a fast method

              Please mark my comment as the Correct Answer if this solution resolved your problem
              • 4. Re: Log the vRO FQDN/IP itself
                lurims Enthusiast

                Thanks for the reply.  I can not do/do not want to do that as that needs a property to be added in all vROs, to be able to execute local OS commands.  I got this error.

                 

                You are not authorized to execute local process, to enable this feature set your system property 'com.vmware.js.allow-local-process' to true

                 

                This should be simple, and there could be some property that should let me do that.  I just want to log the name/fqdn of the vRO in which the workflow is run and I want to log it as part of the log or set as an output variable.

                • 5. Re: Log the vRO FQDN/IP itself
                  qc4vmware Master

                  You'll probably not like this answer but apparently they are never going to simply but this in the /about portion of the vRO api, add it to the plugin, or give us some other out of the box method for retrieving this.  I simply created a config element and populate each vRO server with this.  Its not dynamic but should be a set it and forget it sort of thing.

                  • 6. Re: Log the vRO FQDN/IP itself
                    xian_ Enthusiast

                    System.resolveIpAddress("127.0.0.1")

                     

                    gave me the vRO hostname. Can you try?

                    • 7. Re: Log the vRO FQDN/IP itself
                      lurims Enthusiast

                      Thanks xian for taking time, checking this and for replying. I have tried this.  This resolved localhost in one environment and the actual FQDN in another environment and not consistent.  Could be due to how the guys build the vRO and or vRO version, and I can't dictate that, it is unreliable as it is not consistently giving the FQDN.

                      • 8. Re: Log the vRO FQDN/IP itself
                        xian_ Enthusiast

                        I had the impression that this is the std. configuration of vRO (at least for embedded instances) to have the hostname associated with 127.0.0.1 in /etc/hosts. Of course if your deployments does not follow this then my solution does not work.

                        • 9. Re: Log the vRO FQDN/IP itself
                          eoinbyrne Hot Shot

                          Just an bit of fun, BUT... - If you add the vRO API as a RESTHost (yes, you can do this ) then you can use the following code to request info about the instance - depending on the configuration you might be able to reliably extract the server hostname?

                           

                           

                          On my Lab instance the "/" request produces this info which has the hostname in the reference URLs

                           

                          When I say "depending on the configuration" this refers to things like the following

                          - standalone vRO

                          - embedded vRO instance in a vRA 7.x (which mine is)

                          - Clustered vRO behind a Loadbalanced URL

                          - others I'm probably not thinking of

                           

                          I'd imagine the LB variant might not be of any use since the service *should* probably return the LB URL for any service hrefs....

                           

                          Basically, YMMV but I found this interesting

                          1 person found this helpful
                          • 10. Re: Log the vRO FQDN/IP itself
                            cjoshi Novice

                            Quite interesting and would work pretty well since this is authoritatively populated by a vRO admin.

                            • 11. Re: Log the vRO FQDN/IP itself
                              qc4vmware Master

                              Here is an example of an action that will work without needing the rest plugin.  You should be able to extract the hostname from the principal name of the certificate.

                               

                              var getUrl = "https://localhost:8281/vco/api/server";

                              var urlObject = new URL(getUrl);

                              try {

                              System.debug("Trying port 8281...");

                              var result = urlObject.getContent() ;

                              }

                              catch (err) {

                              System.debug("No api on port 8281.  Trying port 443...");

                              getUrl = "https://localhost:443/vco/api/server";

                              urlObject = new URL(getUrl);

                              var result = urlObject.getContent() ;

                              }

                               

                               

                              // parse results

                              System.debug(result);

                              System.debug("============");

                              var resultObj = JSON.parse(result);

                              System.debug("Issuer Name: "+resultObj["sslCertificate"]["issuerName"]);

                              System.debug("notValidAfter: "+resultObj["sslCertificate"]["notValidAfter"]);

                              System.debug("notValidBefore: "+resultObj["sslCertificate"]["notValidBefore"]);

                              var principalName = resultObj["sslCertificate"]["principalName"];

                              System.debug("principalName: "+principalName);

                              System.debug("thumbprint: "+resultObj["sslCertificate"]["thumbprint"]);

                              System.debug("identityCertificateExists: "+resultObj["sslCertificate"]["identityCertificateExists"]);

                               

                               

                              return principalName;

                              • 12. Re: Log the vRO FQDN/IP itself
                                lurims Enthusiast

                                Seems to be interesting, but I wonder why this has to be this tough, as it could have been baked into the java code of some vro object like System or Server object.  I changed the strategy of sending emails from the Master vRO than from every slave/remote vRO.  Due to this I know which vRO name to append to the email when I check the results of a remote vRO.  Thanks to all.

                                • 13. Re: Log the vRO FQDN/IP itself
                                  lurims Enthusiast

                                  eoinbyrne, thanks for taking time to investigate and post this, appreciated.