AWS認証情報に問題があります。 AWSドキュメントに書かれているように、〜/ .aws/credentialsに作成した認証情報ファイルを使用しました。ただし、Apacheはそれを読み取ることができません。
まず、私はこのエラーを受け取りました:
インスタンスプロファイルメタデータサーバーから資格情報を取得中にエラーが発生しました。 Amazon EC2内で実行していない場合は、クライアントの作成時に「キー」および「シークレット」オプションでAWSアクセスキーIDとシークレットアクセスキーを提供するか、インスタンス化されたAws\Common\Credentials CredentialsInterfaceオブジェクトを提供する必要があります。
次に、インターネットで見つけた解決策をいくつか試しました。たとえば、HOME変数を確認しようとしました。/home/ubuntuでした。自分の資格情報ファイルを/ var/wwwディレクトリに移動しようとしましたが、それが私のWebサーバーディレクトリではない場合でも同様です。何もうまくいきませんでした。それでも同じエラーが発生しました。
2番目の解決策として、CredentialsProviderを直接呼び出して、クライアント上のディレクトリを示すことができることを確認しました。
https://forums.aws.Amazon.com/thread.jspa?messageID=583216򎘰
エラーは変更されましたが、機能させることができませんでした。
/.aws/credentialsから認証情報を読み取れません
また、パスを示す代わりに、CredentialsProviderのデフォルトプロバイダーを使用できることもわかりました。
私が試しましたが、同じエラーが発生し続けます:
/.aws/credentialsから認証情報を読み取れません
この情報が必要な場合に備えて、aws/aws-sdk-php(3.2.5)を使用しています。私が使用しようとしているサービスはAWS Elastic Transcoderです。私のEC2インスタンスはUbuntu 14.04です。 Capifonyを使用してデプロイされたSymfonyアプリケーションを実行します。
この本番サーバーを試す前に、〜/ .aws/credentialsファイルでのみ完全に機能する開発サーバーで試しました。この開発サーバーは、本番サーバーのコピーです。ただし、デプロイメントにはCapifonyを使用しません。これはプロジェクトの通常のgitクローンです。また、EBSボリュームは1つしかありませんが、運用サーバーにはOS用とアプリケーション用があります。
ああ!また、資格情報ファイルの権限/所有者が両方のサーバーで同じであり、それらが同じであるかどうかも確認しました。 777を試して、何も変わらないかどうかを確認しました。
誰かがアイデアを持っていますか?
「Cannot read credentials from /.aws/credentials
」エラーも発生しました。エラーメッセージに解決策が示されています。
/.aws/credentials
は、ルートディレクトリ/
から直接離れたファイルとディレクトリであり、SDKが探している場所です。 Apacheを実行するユーザー(centos7のユーザーApache
)には独自のホームがないため、〜/ homeはありません。
これに関するいくつかの警告はaws docsにあるはずです!
/.aws/credentials
ではなく~/user/.aws/credentials
とまったく同じように認証情報ファイルを作成します
完璧に動作します。
Selinuxをenforcingに設定した場合、httpdのセキュリティコンテキストに一致するように./awsのセキュリティコンテキストを再帰的に変更する必要があります。そうしないと、Apacheは資格情報ファイルを読み取ることができません。
Sudo chcon -Rv --type = httpd_sys_content_t /.aws
$ ls -Z /.aws/credentials -rwxr-xr-x。ルートルートunconfined_u:object_r:httpd_sys_content_t:s0 /.aws/credentials
EC2インスタンスから実行している場合、ベストプラクティスは、認証情報を保存する代わりにIAMロールを使用することです。 [IAM]> [ロール]> [ロールの作成]に移動し、ロールを作成して、このロールに必要な権限を付与したポリシーをアタッチします(必要に応じて、これについてお手伝いします)。次に、EC2マシンを作成し、「ステップ3:インスタンスの詳細を構成する」のときに、このロールをマシンにアタッチします。今後は、マシンに資格情報を保存する必要はありません。awsAPIへの呼び出しはすべて「自動的に」署名されます。
既存のマシンにロールをアタッチする場合は、マシンからAMIを作成し、ロールがアタッチされた新しいVMをこのAMIから作成する必要があります。
私が行うことは、少なくとも空のロールを常にVMにアタッチすることです。これにより、必要に応じて、後でポリシーにこのロールをアタッチし、マシンがAPIを呼び出せるようにすることができます。
これが誰かを助けることができるならば、私は私の方法で.iniファイルを機能させることができました:
$profile = 'default';
$path = '/mnt/app/www/.aws/credentials/default.ini';
$provider = CredentialProvider::ini($profile, $path);
$provider = CredentialProvider::memoize($provider);
$client = ElasticTranscoderClient::factory(array(
'region' => 'eu-west-1',
'version' => '2012-09-25',
'credentials' => $provider
));
CredentialProviderはこのドキュメントで説明されています:
http://docs.aws.Amazon.com/aws-sdk-php/v3/guide/guide/credentials.html#ini-provider
アプリケーションが1つのサーバーのホームディレクトリ(〜/ .aws/credentials/default.ini)にあるファイルを読み取れないが、他のサーバーでは読み取れる理由がまだわかりません。
誰かがそれについて何か知っているなら、私に知らせてください。