Sync up vCenter Server with NTP: Bug and Workaround

While playing with VMware Single Sign On (SSO) SDK, I got into an exception indicating that the request had expired.

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Request has expired
	at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
	at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
	at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
	at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
	at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
	at $Proxy40.issue(Unknown Source)
	at com.vmware.sso.client.samples.AcquireHoKTokenByUserCredentialSample.getToken(AcquireHoKTokenByUserCredentialSample.java:233)
	at com.vmware.sso.client.samples.AcquireHoKTokenByUserCredentialSample.main(AcquireHoKTokenByUserCredentialSample.java:285)

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

Initially I thought it might be caused by timestamps in the arguments sent to SSO server. But further investigation showed that the time on my vCenter appliance server had run 3 hours faster than normal, so whatever request I had submitted from my desktop (whose time is up to the date) was “thought” to be submitted 3 hours ago. No wonder the request was rejected as expired. I think there is an allowance of a few minutes and 3 hours was just too big to ignore.

Once the issue was isolated, the solution should be simple – sync up the clock with NTP. It turned out that is not quite as easy as it should be.

According to VMware online document, you can use the following two commands to set up time server: (I got one of the servers listed at http://tf.nist.gov/tf-cgi/servers.cgi)

# yast2 ntp-client add server=time.nist.gov
Error:
Cannot update the dynamic configuration policy.
# yast2 ntp-client enable

These two commands did not actually work with error as shown above. It should not be an issue with the permission as they were run as root user.

The last command listed in the page worked just fine. The second command showed the updated timestamp.

# sntp –P no –r time.nist.org
# date

After a bit Web searching, I got this blog whose author had done good research and found it’s a bug in SUSE (vCenter appliance is based SUSE Linux). The workaround given there is to edit the /etc/ntp.conf and add the following line and restart with “rcntp start” command.

server pool.ntp.org dynamic

After changing this, I haven’t gone back and check if it works. I guess it’s not easy for the time to shift big enough to be noticed or fail my test with SSO in any short time.

This entry was posted in Virtualization and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  • NEED HELP?


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.