[
https://issues.apache.org/jira/browse/HADOOP-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972692#comment-15972692
]
Steve Loughran commented on HADOOP-14291:
-----------------------------------------
+maybe we could actually print the MD5 hashes of the secrets. That way, you can
verify that the secrets used in the bucket are the same as those you hold
—without us disclosing the secrets in a way which can be considered a security
leak.
Maybe here each provider should have the ability to provide a diagnostics
string; the key-one would list the hashed property & provenance; the env one
would declare they came from the env vars (and again, the # values).
> S3a "No auth" message to include diagnostics
> --------------------------------------------
>
> Key: HADOOP-14291
> URL: https://issues.apache.org/jira/browse/HADOOP-14291
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 2.8.0
> Reporter: Steve Loughran
>
> There's a whole section in s3a troubleshooting because requests can get auth
> failures for many reasons, including
> * no credentials
> * wrong credentials
> * right credentials, wrong bucket
> * wrong endpoint for v4 auth
> * trying to use private S3 server without specifying endpoint, so AWS being
> hit
> * clock out
> * joda time
> ....
> We can aid with debugging this by including as much as we can in in the
> message and a URL To a new S3A bad auth wiki page.
> Info we could include
> * bucket
> * fs.s3a.endpoint
> * nslookup of endpoint
> * Anything else relevant but not a security risk
> Goal; people stand a chance of working out what is failing within a bounded
> time period
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
