Unable to Connect Serengeti to BDE - Check Certificate Failed?

[ExpletiveDelete]

Using BDE 1.1 and Serengeti .0.8. I can install both OVAs fine, and get BDE registered, but when trying to connect a serengeti server with the error "Check certificate failed. Select a correct Serengeti server".

I can't find anything on this. Does anyone have any ideas on this? any direction to point me in?

Much appreciated.

[gguanglu]

BDE is a super set of Serengeti, which doesn't include GUI and other valuable additions. And Serengeti 0.8 is a pretty old version, you could think BDE 1.1 is based on Serengeti 1.1.

Please use BDE 1.1 web client plugin to connect BDE (or Serengeti) 1.1 management server.

[ExpletiveDelete]

I've tried both. Currently the BDE version I'm using is 1.1.0.568. Now I get the "Connection Failed! Check the server has enabled SSO." error. So I ran the EnableSSOAuth command in the BDE server and it ran successfully. Stopped and started tomcat with no problems, I get the same 'SSO' error. I've bounced the vCenter box, restarted and reinstalled everything I can think of and STILL i get the SSO error. The only thing i can think of would be adding the serengeti account to the @domain.local users group in the SSO. I have no idea at this point.

[MichaelWest]

Are you able to connect through the CLI with the same SSO account?

Have you installed earlier versions of the BDE plugin into this vCenter?

There is a web client issue where you install a plugin, uninstall it, then install a later build with similar versioning.

In this case, the later plugin build does not get installed.

The steps to resolve this are detailed in the Troublshooting section of the Administrator's guide.

http://pubs.vmware.com/bde-1/topic/com.vmware.ICbase/PDF/vsphere-big-data-extensions-10-admin-user-g...

[ExpletiveDelete]

I've installed the serengeti server (v0.8) which is apparently the earlier version of BDE. I can bring up the CLI interface, but it won't accept either the local serengeti account or any AD / vCenter or SSO account. " The Connection is refused, may be invalid username or invalid password. Try to reconnect". I've not created another account on the serengeti server. The troubleshooting section comes up short on just standing things up... I didn't see anything re: removing any 'old' versions. pages 75-84? I couldn't find anything of note in the logs - nothing that "stood out" anyway.

[MichaelWest]

Its page 82 in the 1.0 admin guide (link in my last comment).  Having said that, I don't think this is your issue.  Even with the wrong plugin version, you would be able to connect in the CLI (BTW, did you use port 8443 instead of 8080?  it changed between Serengeti/Beta and the version you are trying now).

We should verfiy that vcenter and the BDE management server are pointing to the same place for SSO.

Login in the management server and check the file /opt/serengeti/ssotool/ssoData/ssoLocations.txt

Compare it with the location for SSO in vcenter.

More than likely, your issue is time synchronization.

It is also important to make sure that NTP is enabled.  Vcenter, your hosts and the Management server must have times that are very close to each other or SSO will not authenticate properly

[ExpletiveDelete]

There is no /opt/serengeti/ssotool/ssoData/ folder, only a /opt/serengeti/ssotool/ and the only folder in that directory is 'lib'.

Aside from that, the vcenter and hosts are all good on NTP services. I did notice that I've got 5 different instances of Serengeti Management Server under my vCenter Server Extensions within the web client. Could that be the issue? How would I clear that? I can only un-register the BDE extension once.

Also, when I go to the SSO link (https://VC-FQDN:7444/lookupservice/sdk) to verify if its running (everything is installed on a single vCenter server), i get the following error:

<?xml version="1.0" encoding="UTF-8"?>

-<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

     -<soapenv:Body>

          -<soapenv:Fault>

               <faultcode>ServerFaultCode</faultcode>

               <faultstring>Unexpected EOF in prolog at [row,col {unknown-source}]: [1,0]</faultstring>

               -<detail>

                    <RuntimeFaultFault xmlns:vim25="urn:vim25" xmlns="urn:vim25" xsi:type="vim25:InvalidRequest"/>

               </detail>

          </soapenv:Fault>

     </soapenv:Body>

</soapenv:Envelope>

Message was edited by: ExpletiveDeleted

[MichaelWest]

By instances, you mean that you have deployed the vapp 5 times so there are 5 different Management Server VMs?  if so, you can just delete the vapps/VMs you don't want to use and then follow the steps in the link I posted above to remove the web client plugin.  After that, you can reinstall the plugin for the Management Server that you did not delete.  Check the SSO data in the Management Server you want to use at the link I sent you previously to verify if SSO has been enabled and is pointing the right place.

I've also forwarded this to a couple of Engineers to take a look.  They may respond over night.

[JunW]

I think you can make sure CLI works first as below:

Once you run EnableSSOAuth successfully, you will find the /opt/serengeti/ssotool/ssoData directory as Michael pointed above. Please use a bde 1.0 or 1.1 version with which we have a bug fix for sso authentication. Then you can try 'serengeti' on the management server, and see if you can login from cli with your login name/password(please note this account must have read privilege on the management server. Otherwise, it will be refused by VC authentication, which CLI relies on. Thus, for simplicity, if possible, please use an administrator account to verify here first). 

[ExpletiveDelete]

No dice. None of the suggestions have worked. I've completely removed and reinstalled vCenter (keeping the same backend DB). I am unable to remove the 'extra' server extensions (now total 6). Also, While I am able to install all components of vCenter, VUM, etc... on the same server, using the same SSO account (Administrator@vsphere.local), even the "EnableSSOAuth" command is now failing. I am unable to reach the lookupservice/sdk page getting the same error as above.

looking more like an SSL problem - buuutu everything else is working fine. I don't want to mess with the vCenter SSL (everything is installed on a single vCenter VM).

any more ideas? or direction on how to fix the SSL issue without destroying everything else?

Message was edited by: ExpletiveDeleted

[gguanglu]

> I did notice that I've got 5 different instances of Serengeti Management Server under my vCenter Server Extensions within the web client. Could that be the issue? How would I clear that?

> I am unable to remove the 'extra' server extensions (now total 6).

If you are talking about the extension names in vSphere web client UI "administration" -> "solutions" -> vCenter Server Extenions" list, then that's probably not relative to SSL certificate issue. This is just an extension registration mechanism for BDE server. So far we only have register/unregister functions open for BDE client plugin, that's where you could do at https://BDE-server-IP-hostname:8443/register-plugin page. But we generally don't unregister BDE server from vCenter, while BDE server is registered to vCenter server as a solution/extension when OVA installation.

If you really think these multiple instances show in UI is annoying, you could go to https://vCenter-IP-hostname/mob/?moid=ExtensionManager with your vCenter administrator credential, and copy the relative extension instance name like "com.vmware.aurora.vcext.instance-e3", then click "UnregisterExtension" below that in the same page. Within the popup page, page the instance name like "com.vmware.aurora.vcext.instance-e3" (without quote) into the VALUE text box, then click invoke method. Go back to the "extension manager" page, F5 or refresh the page, you won't see the instance any more. And in vSphere web client, you won't see the solution instance there any more after refresh too.

[ExpletiveDelete]

I tried that after reading KB 1025360 - and it 'seems' to work on refresh, but even after service restarts and even a reboot the extensions remain visible under Administration > Solutions > vCenter Server Extensions>

Its not too big of an issue - more annoying than anything. I just want to make sure that they aren't the problem (installing an extension it sees as already being installed).

As it stands, its pretty much a messy cluster- and we won't be able to implement it as it stands. Even with our VMware rep and this forum, there isn't much support for BDE, let alone the confusion between the old Serengeti and the new BDE which is still Serengeti.

[MichaelWest]

Please keep in mind that BDE is a supported product.  If you have vSphere Enterprise or Enterprise Plus, you can use GSS for support.  This forum is meant as a supplement to that support.  I suggest that you open a ticket with GSS so that they can directly help you with troubleshooting your issue.

[ExpletiveDelete]

yeah, I've had a ticket opened in 28-March. Seeing as this is a POC, I think I'll drop it/back burner until it matures a little more. Maybe -6 will add a better interface, less confusion, etc....

Google "VMware Serengeti" and see how many different entries you get. Is it Serengeti (old) or BDE ('new' Serengeti)? and to which does the paperwork/guides refer?

Thanks.

I hated SSL even before heartbleed.

[MichaelWest]

I know this is confusing.  Serengeti is the open source project we started in 2012.  BDE is the enterprise version of Serengeti that is fully supported by VMware.  Is is essentially the same code.  You want to be on at least BDE 1.0 to get support from GSS.  If you email me your ticket number I will check with GSS to see what activity has occured.  mwest@vmware.com

[mkian]

Can your vCenter reach to your Serengeti server? Can it ping it? They should be on the same network.