On Tuesday 21 August 2012 06:02:24 Scott Moser wrote:
> The solution that seems to make the most sense to me there is to
> attempt to fix the clock to the server's clock if an Oauthed request fails
> with 403. I'm concerned that the clock jumping forward or backward at
> this point in boot might have negative affects. There are possibly some
> things that are sleeping and would have issues with backwards or greatly
> forwards moving clock (dhclient is likely one).
It may be possible to coerce OAuth into using a special timestamp instead of
violently modifying the system clock. It needs a change in cloud-init of
course.
Once you have an OAuthRequest object, you can call this before calling
sign_request:
>>> request.set_parameter("oauth_timestamp", <value>)
<value> normally defaults to "int(time.time())". It should be easy to poke
the server's value in that you determined earlier.--
Mailing list: https://launchpad.net/~maas-devel
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maas-devel
More help : https://help.launchpad.net/ListHelp
