Error retrieving credentials from the instance profile metadata service

After update Version 3.187.0 = DynamoDB Error retrieving credentials from the instance profile metadata #2281

I current use this environment

aws/aws-sdk-php 3.186.4 AWS SDK for PHP — Use Amazon Web Services in your PH.
aws/aws-sdk-php-laravel 3.6.0 A simple Laravel 5/6/7/8 service provider for includ
laravel/framework v8.53.0 The Laravel Framework.
laravel/nova 3.27.0 A wonderful administration interface for Laravel.

If I execute composer update for upgrade SDK version 3.187.0 receive this. The problem is DynamoDB thatt i use for driver Cache and Session in Laravel. If change Driver from DYNAMODB to FIle.. no reveive error, but if i use dynamodb exception in all pages my application..

If downgrade return all OK

The text was updated successfully, but these errors were encountered:

@massimodellarovere I think I know what caused this, and am working on a fix right now. Please stand by

@massimodellarovere, just merged the fix. Please get the latest then try again and let me know if it’s fixed

Update with dev-master is OK .. I not receive error

@SamRemis This is still an issue with production and affects more services than just DynamoDB, when will this be merged?

@SamRemis Any idea on the ETA for this one being merged in and released as a tagged version? It’s wiped a fair few systems out.

@jonnycbw @mgilberties I have already merged it, so depending on how you download the release, it should have already been fixed. I will release a tagged version to make sure it propagates faster

In case I’m wrong, I could use a larger error message to know for sure what the issue is

@SamRemis — Nice one. We were installing using composer and it doesn’t appear to be pulling the latest changes without the tag. We have manually set our systems to use 3.186.1 for now. This is the error we were getting across numerous instances:

[2021-08-04 12:00:51] uat.ERROR: Error retrieving credentials from the instance profile metadata service. (cURL error 6: Could not resolve host: https (see https://curl.haxx.se/libcurl/c/libcurl-errors.html$ [stacktrace] #0 /var/app/current/vendor/aws/aws-sdk-php/src/Credentials/InstanceProfileProvider.php(159): Aws\Credentials\InstanceProfileProvider->handleRetryableException(Object(GuzzleHttp\Exception\ConnectExceptio$ #1 [internal function]: Aws\Credentials\InstanceProfileProvider->Aws\Credentials\() #2 /var/app/current/vendor/guzzlehttp/promises/src/Coroutine.php(160): Generator->throw(Object(GuzzleHttp\Exception\ConnectException)) #3 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(204): GuzzleHttp\Promise\Coroutine->_handleFailure(Object(GuzzleHttp\Exception\ConnectException)) #4 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(153): GuzzleHttp\Promise\Promise::callHandler(2, Object(GuzzleHttp\Exception\ConnectException), NULL) #5 /var/app/current/vendor/guzzlehttp/promises/src/TaskQueue.php(48): GuzzleHttp\Promise\Promise::GuzzleHttp\Promise\() #6 /var/app/current/vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php(118): GuzzleHttp\Promise\TaskQueue->run() #7 /var/app/current/vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php(145): GuzzleHttp\Handler\CurlMultiHandler->tick() #8 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttp\Handler\CurlMultiHandler->execute(true) #9 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttp\Promise\Promise->invokeWaitFn() #10 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(269): GuzzleHttp\Promise\Promise->waitIfPending() #11 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttp\Promise\Promise->invokeWaitList() #12 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending() #13 /var/app/current/vendor/guzzlehttp/promises/src/Coroutine.php(67): GuzzleHttp\Promise\Promise->wait() #14 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttp\Promise\Coroutine->GuzzleHttp\Promise\(true) #15 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttp\Promise\Promise->invokeWaitFn() #16 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending() #17 /var/app/current/vendor/guzzlehttp/promises/src/Coroutine.php(103): GuzzleHttp\Promise\Promise->wait(false) #18 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(274): GuzzleHttp\Promise\Coroutine->wait(false) #19 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttp\Promise\Promise->invokeWaitList() #20 /var/app/current/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending() #21 /var/app/current/vendor/aws/aws-sdk-php/src/S3/S3Client.php(460): GuzzleHttp\Promise\Promise->wait() #22 /var/app/current/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemAdapter.php(561): Aws\S3\S3Client->createPresignedRequest(Object(Aws\Command), Object(Illuminate\Support\Carbon)) #23 /var/app/current/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemAdapter.php(534): Illuminate\Filesystem\FilesystemAdapter->getAwsTemporaryUrl(Object(League\Flysystem\AwsS3v3\AwsS3Adap$ #24 /var/app/current/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php(399): Illuminate\Filesystem\FilesystemAdapter->temporaryUrl(‘project-name/even. ‘, Object(Illuminate\Support\$

@mgilberties Thanks 🙂 that’s really helpful! I wonder if this issue is releated only to presigned requests. I will be looking into it more once the issue is definitely clear. I did just release tag 3.187.1, so hopefully everyone should have this fixed now.

Actually I spoke too soon, it looks like it’s taking a bit to update on composer; I’ll see what I can do to speed that up.

There it goes, should be available now for 3.187.1

@mgilberties please confirm this is fixed if you get the chance so I can close this issue out

@SamRemis — I can confirm that we now have v3.187.1 getting picked up and everything is functioning as expected. Thanks for your quick actions and response 🙌

I hit this issue this morning after rebuilding a Docker image for MediaWiki —

Posting this here in case it helps anyone else. Had me worried there! Super appreciate @massimodellarovere for reporting the issue and the quick fix, @SamRemis. As soon as I saw the release notes I was pretty sure I could revert to an older version, but it’s great this has been patched.

Great 🙂 this should be working for everyone now, but I’ll set this issue to closing soon just to give it a few days if anyone runs into it.

Источник

Error retrieving credentials from the instance profile metadata service #1530

Description

Error retrieving credentials from the instance profile metadata service. (cURL error 28: Connection timed out after 1001 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for http://169.254.169.254/latest/meta-data/iam/security-credentials/) (View: /var/www/html/vendor/area17/twill/views/layouts/dashboard.blade.php)

Steps to reproduce

Expected result

Dashboard should open.

Actual result

Error retrieving credentials from the instance profile metadata service. (cURL error 28: Connection timed out after 1001 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for http://169.254.169.254/latest/meta-data/iam/security-credentials/) (View: /var/www/html/vendor/area17/twill/views/layouts/dashboard.blade.php)

Versions

Twill: 2.8.0-beta.2
Laravel: v9.5.1
PHP: 8.1.3
Database: MySQL 8.0.28-1.2.7-server

The text was updated successfully, but these errors were encountered:

The issue above seems to be related to AWS and S3, even after swapping my media library to using the local storage the issue persists.

Turns out regardless of your media library configuration you will still need to set up AWS and S3, this fixed the issue for me.

The media library does not need aws nor s3 to work locally.

@joaocagnoni make sure you have at least this in your .env if working with local storage:

Thanks @haringsrob for the heads up with the FILE_LIBRARY_ENDPOINT_TYPE, that worked well. might be good to update the docs so that this is mentioned here https://twill.io/docs/getting-started/installation.html#setting-up-the-media-library

Thank you @haringsrob, it worked. I agree with @plexus77, the docs should be updated with this env variable as all other new users may be in the same situation.

This is all updated in the 3.x docs where this is the default now :). Will see if I can add it to current docs as well.

Hi… brand new user here. I was getting this error trying to set up Twill under Valet on my Mac. Adding MEDIA_LIBRARY_ENDPOINT_TYPE=local (etc.) to my .env file indeed solved the problem, and I do see now that the documentation mentions it.

But since I got stuck on the error message in the immediate prior section («Accessing the admin console»), I didn’t even bother to read on. It may be useful to add a prominent callout right there in the documentation indicating that a local setup is likely to get this error without making the necessary .env changes, or maybe even move that section below «Setting up the media library,» to avoid confusion. (Thanks!)

Hi @room34, definitely. In Twill 3 (currently in beta), the local setup is the default to avoid this confusion on the first install.

The media library does not need aws nor s3 to work locally.

@joaocagnoni make sure you have at least this in your .env if working with local storage:

This works for me !

Closing this issue. In Twill 3 the default is all local setup.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Error retrieving credentials from the instance profile metadata server. (Client error: GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ resulted in a 404 Not Found #2068

Hi
I got this error while connecting AWS Managed Elasticsearch. But My code does not provide any error on my local environment. I have shared my both environment specification below:

Local Environment:

AWS CLI version:

Dev Environment:

AWS CLI version:

I have check the aws credentials both of local and dev server using cat

/.aws/credentials and they are the same.

I have added both of my local and dev server public ip on elasticsearch access policy.

Below I have added my PHP code:

Service class for getting client:

I got success data on my local environment. But on dev environment I got error response where the error message is :

Help me find my problem.

The text was updated successfully, but these errors were encountered:

Hi @Tarequzzaman, thanks for reaching out to us. While version 3.90.6 of the AWS SDK for PHP is relatively old and I recommend upgrading to the latest version of the SDK to ensure recent changes in service APIs are supported, there haven’t been any significant changes in how the SDK handles credentials from the shared credential file since that version so this shouldn’t affect your ability to load the credentials you’re trying to use.

Based on the error you’re seeing it sounds like the AWS SDK for PHP is not finding a credentials file in the default path within your dev environment so it’s continuing down the default provider chain to retrieve instance profile credentials. Is the code in your dev environment being run as the same user that has the .aws/credentials file in its home directory? If not, you’ll want to ensure this file is present in the correct home directory so the SDK is able to locate and open it.
Alternately, you can configure an ini provider in place of the default credential provider and specify the absolute path of your credentials file. This of course will require the user running your PHP process to have at least read access to the credentials file.

Источник

AwsExceptionCredentialsException Timeout #2022

Describe the bug
Occasionally get the following error message.

AwsExceptionCredentialsException: Error retrieving credentials from the instance profile metadata server. (cURL error 28: Connection timed out after 1000 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)) in /var/www/mysite/vendor/aws/aws-sdk-php/src/Credentials/InstanceProfileProvider.php:240

Seems to be fine most of the time, but we randomly get the error messages above in our logs.

Version of AWS SDK for PHP?
v3.135.3

Version of PHP ( php -v )?
7.0.33

To Reproduce (observed behavior)

Expected behavior

Screenshots

Additional context
It is running on EC2 and we are using the instance profile to provide the credentials.

The text was updated successfully, but these errors were encountered:

Thanks for reaching out to us @Tbone542. By default, the instance profile provider has a timeout of 1 second with 3 retries before returning the exception you’re seeing. It sounds like your application is attempting to retrieve credentials from the instance’s metadata service more frequently than it can handle returning credentials within the given timeout. There’s a couple of things you could do to avoid this behavior.

• Initialize an instance profile provider with increased values for timeout and/or retries

This will allow the instance metadata service more time to respond with credentials before the SDK returns an error, but will result in longer times to initialize a service client and issue API calls to the service in question. You can review the parameters the instance profile provider accepts here. Depending on your use case (whether you’re initializing multiple service clients within the same script) you may want to memoize the credentials returned by the instance profile provider to reduce the amount of calls to the instance metadata service

• Cache a provider’s credentials in a CacheInterface and retrieve credentials from the cache

This will result in the SDK only retrieving credentials from the instance metadata service when the cached credentials have expired. You’ll still need to specify a provider to use when caching credentials, but you shouldn’t have to provide special configuration parameters to account for the rate at which the instance metadata service can respond to requests. While the example below shows usage for a Doctrine filesystem cache, the CacheInterface also supports PsrCacheCacheItemPoolInterface, PsrSimpleCacheCacheInterface and LruArrayCache.

Источник

Good morning!

I hit this issue this morning after rebuilding a Docker image for MediaWiki —

AwsExceptionCredentialsException from line 272 of /var/www/html/vendor/aws/aws-sdk-php/src/Credentials/InstanceProfileProvider.php: Error retrieving credentials from the instance profile metadata service. (cURL error 6: Could not resolve host: https (see https://curl.haxx.se/libcurl/c/libcurl-errors.html))
#0 /var/www/html/vendor/aws/aws-sdk-php/src/Credentials/InstanceProfileProvider.php(159): AwsCredentialsInstanceProfileProvider->handleRetryableException(Object(GuzzleHttpExceptionConnectException), Array, 'Error retrievin...')
#1 [internal function]: AwsCredentialsInstanceProfileProvider->AwsCredentials{closure}()
#2 /var/www/html/vendor/guzzlehttp/promises/src/Coroutine.php(160): Generator->throw(Object(GuzzleHttpExceptionConnectException))
#3 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(204): GuzzleHttpPromiseCoroutine->_handleFailure(Object(GuzzleHttpExceptionConnectException))
#4 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(153): GuzzleHttpPromisePromise::callHandler(2, Object(GuzzleHttpExceptionConnectException), NULL)
#5 /var/www/html/vendor/guzzlehttp/promises/src/TaskQueue.php(48): GuzzleHttpPromisePromise::GuzzleHttpPromise{closure}()
#6 /var/www/html/vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php(118): GuzzleHttpPromiseTaskQueue->run()
#7 /var/www/html/vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php(145): GuzzleHttpHandlerCurlMultiHandler->tick()
#8 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttpHandlerCurlMultiHandler->execute(true)
#9 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttpPromisePromise->invokeWaitFn()
#10 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(269): GuzzleHttpPromisePromise->waitIfPending()
#11 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttpPromisePromise->invokeWaitList()
#12 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttpPromisePromise->waitIfPending()
#13 /var/www/html/vendor/guzzlehttp/promises/src/Coroutine.php(67): GuzzleHttpPromisePromise->wait()
#14 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttpPromiseCoroutine->GuzzleHttpPromise{closure}(true)
#15 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttpPromisePromise->invokeWaitFn()
#16 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttpPromisePromise->waitIfPending()
#17 /var/www/html/vendor/guzzlehttp/promises/src/Coroutine.php(103): GuzzleHttpPromisePromise->wait(false)
#18 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(274): GuzzleHttpPromiseCoroutine->wait(false)
#19 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttpPromisePromise->invokeWaitList()
#20 /var/www/html/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttpPromisePromise->waitIfPending()
#21 /var/www/html/vendor/aws/aws-sdk-php/src/AwsClientTrait.php(58): GuzzleHttpPromisePromise->wait()
#22 /var/www/html/vendor/aws/aws-sdk-php/src/ResultPaginator.php(127): AwsAwsClient->execute(Object(AwsCommand))
#23 /var/www/html/vendor/aws/aws-sdk-php/src/functions.php(52): AwsResultPaginator->valid()
#24 /var/www/html/vendor/aws/aws-sdk-php/src/functions.php(69): Awsmap(Object(AwsResultPaginator), Object(Closure))
#25 [internal function]: Awsflatmap(Object(AwsResultPaginator), Object(Closure))
#26 /var/www/html/extensions/AWS/s3/AmazonS3FileBackend.php(550): Generator->valid()
#27 /var/www/html/includes/libs/filebackend/FileBackendStore.php(1105): AmazonS3FileBackend->doDirectoryExists('mediawiki-local...', 'temp/', Array)
#28 /var/www/html/includes/installer/DatabaseUpdater.php(1166): FileBackendStore->directoryExists(Array)
#29 /var/www/html/maintenance/update.php(199): DatabaseUpdater->setFileAccess()
#30 /var/www/html/maintenance/doMaintenance.php(107): UpdateMediaWiki->execute()
#31 /var/www/html/maintenance/update.php(253): require_once('/var/www/html/m...')
#32 {main}

Posting this here in case it helps anyone else. Had me worried there! Super appreciate @massimodellarovere for reporting the issue and the quick fix, @SamRemis. As soon as I saw the release notes I was pretty sure I could revert to an older version, but it’s great this has been patched.