-
Improvement
-
Resolution: Fixed
-
Minor
-
s3-plugin 0.6, or 0.7-SNAPSHOT; Jenkins 1.573 or 1.574-SNAPSHOT
The S3 plugin is very sensitive to clock drift on the Jenkins server, as it signs download URLs with a 4000ms (4s) expiry.
This results in errors like:
<Error>
<Code>AccessDenied</Code>
<Message>Request has expired</Message>
<RequestId>DBB502010D433E63</RequestId>
<Expires>2014-07-21T06:44:37Z</Expires>
<HostId>
0RLt34WZ9rebc7yijszDZ2gquwYBMj1OENPUtc9KAVtXsATJPdwxoYatu3/+2QOB
</HostId>
<ServerTime>2014-07-21T06:47:58Z</ServerTime>
</Error>
which won't be super-informative to the user.
I suggest two changes.
First, default to a longer expiry, say 60 seconds, that allows for things like a little packet loss / a high latency connection / etc, and a little clock drift.
Second, document the need for NTP to keep up reasonable clock sync.
I'll follow up with a patch for both.
[JENKINS-23897] S3 plugin's signed URL expiry is extremely sensitive to clock drift
Craig Ringer
created issue -
Craig Ringer
made changes -
| Description |
Original:
The S3 plugin is very sensitive to clock drift on the Jenkins server, as it signs URLs with a 4000ms (4s) expiry. This results in errors like: {code} <Error> <Code>AccessDenied</Code> <Message>Request has expired</Message> <RequestId>DBB502010D433E63</RequestId> <Expires>2014-07-21T06:44:37Z</Expires> <HostId> 0RLt34WZ9rebc7yijszDZ2gquwYBMj1OENPUtc9KAVtXsATJPdwxoYatu3/+2QOB </HostId> <ServerTime>2014-07-21T06:47:58Z</ServerTime> </Error> {code} which won't be super-informative to the user. I suggest two changes. First, default to a longer expiry, say 60 seconds, that allows for things like a little packet loss / a high latency connection / etc, and a little clock drift. Second, document the need for NTP to keep up reasonable clock sync. I'll follow up with a patch for both. |
New:
The S3 plugin is very sensitive to clock drift on the Jenkins server, as it signs download URLs with a 4000ms (4s) expiry. This results in errors like: {code} <Error> <Code>AccessDenied</Code> <Message>Request has expired</Message> <RequestId>DBB502010D433E63</RequestId> <Expires>2014-07-21T06:44:37Z</Expires> <HostId> 0RLt34WZ9rebc7yijszDZ2gquwYBMj1OENPUtc9KAVtXsATJPdwxoYatu3/+2QOB </HostId> <ServerTime>2014-07-21T06:47:58Z</ServerTime> </Error> {code} which won't be super-informative to the user. I suggest two changes. First, default to a longer expiry, say 60 seconds, that allows for things like a little packet loss / a high latency connection / etc, and a little clock drift. Second, document the need for NTP to keep up reasonable clock sync. I'll follow up with a patch for both. |
Craig Ringer
made changes -
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Craig Ringer
made changes -
| Status | Original: In Progress [ 3 ] | New: Open [ 1 ] |
Craig Ringer
made changes -
| Labels | Original: s3 timeout | New: patch pull_request s3 timeout |
Craig Ringer
made changes -
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Workflow | Original: JNJira [ 156762 ] | New: JNJira + In-Review [ 195496 ] |
