search

timkay / aws

Easy command line access to Amazon EC2, S3, SQS, ELB, and SDB
http://timkay.com/aws/
424 stars 123 forks source link

Local time sanity check fail #96

Open avnr opened 9 years ago

avnr commented 9 years ago

I've been working with your truly awesome aws for years, until a while ago I started getting the error sanity-check: Problems accessing AWS. Is curl installed?. After some digging I found that the target S3 host (Dreamhost, using Ceph) has dropped the Date: header from their responses, which got aws kinda confused.

For the sake of other users who might encounter this problem it might be beneficial to gracefully handle such a situation. I didn't make a PULL request as I'm not entirely sure why this check is needed, AFAIAC this test can be skipped. Alternatively it would be possible to alert about the absence of the Date: header, and/or check the time against NIST.

timkay commented 9 years ago

Thanks for the great feedback! I'm glad "aws" has been working for you.

"aws" does this sanity check because lots of users ran into problem without it. By default, "aws" signs requests to be valid for 30 seconds. If your computer's clock is off by more than 30 seconds, then all your requests would be expired the instant they are signed. I added the sanity check to do two things. First it warns the user that the clock is off. Second, it computes the clock offset, and it uses the result to adjust the signing of all requests. After the signing request (and the possible display of the warning that your clock is off), requests will succeed anyway because of the offset.

If you don't want the sanity check, you can either add --sanity-check to turn off sanity check (poorly named, I know), or create a ~/.awsrc file. The existence of that file will disable sanity checks. A second consequence of turning off sanity checks is that requests will be processed faster.

avnr commented 9 years ago

Thanks for the quick response!

I indeed turned off sanity check once I diagnosed the problem and that worked for me, no complaints. I just thought of saving the time of other users who might run into this same problem. We're using the script in production scenarios and when it failed we had to do tons of stuff manually until I had a few hours to investigate what went wrong. If the script would have been aware that the S3 host didn't send the Date: header and suggest some graceful alternative then we could have saved plenty of time.

All that said, documenting the script's behavior in this thread is already a partial solution, should it come up in the search result of someone in need.

timkay commented 9 years ago

You make a great point: If it fails to find a Date: header, then it should behave better. I'll make that change.