Mike,
I've ended up firing a EC2 instance and I did replicate with my private
bucket too.
With a EC2 Ubuntu 22.04 instance, on a minimal GDAL master debug build,
things work fine with IAM authentication, in the VM itself
But if I run inside a ubuntu:22.04 Docker image the same build (mounting
my home directory), then I got exactly the same symptoms as you!
I finally figured out that the "curl -X PUT
"http://169.254.169.254/latest/api/token"; -H
"X-aws-ec2-metadata-token-ttl-seconds: 10" request for IDMSv2 was
failing inside Docker but not in the outside EC2 VM. Known (intended)
issue according to
https://community.grafana.com/t/imdsv2-is-not-working-from-docker/65944
The solution/workaround is to run docker with --network=host (I guess it
could be possible to restrict it a bit to just 169.254.169.254)
In https://github.com/OSGeo/gdal/pull/6752, I've pushed a proper fix,
that makes sure that the fallback to IDMSv1 works by clearing the GDAL
error state (which was the reason for the weird behaviour that
GDALOpen() only worked the second time), and emits a hopefully debug
hint when it sees that IDMSv2 fails on timeout inside a Docker container.
With the fix, when trying inside a Docker with default networking rules:
# gdalinfo /vsis3/XXXXXXX/byte.tif --debug on
AWS: AWS_ROLE_ARN configuration option not defined
HTTP: Fetch(http://169.254.169.254/latest/api/token)
HTTP: libcurl/7.81.0 GnuTLS/3.7.3 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8
libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib
nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13
HTTP: Fetch(http://169.254.169.254/latest/meta-data)
S3: /latest/api/token EC2 IDMSv2 request timed out, but /latest/metadata
succeeded. Trying with IDMSv1. Try running your Docker container with
--network=host.
HTTP:
Fetch(http://169.254.169.254/latest/meta-data/iam/security-credentials/)
HTTP:
Fetch(http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2_s3)
AWS: Storing AIM credentials until 2022-11-20T23:38:10Z
S3: Switching to region eu-central-1
S3: Downloading 0-1796 (https://XXXXXXX.s3.amazonaws.com/byte.tif)...
S3: Got response_code=206
GDAL: GDALOpen(/vsis3/XXXXXXX/byte.tif, this=0x5599cfbce470) succeeds as
GTiff.
It was an "interesting" bug...
Even
Le 20/11/2022 à 14:47, Michael Smith a écrit :
Is there a reason why OpenEx would work but Open wouldn’t?
In [1]: from osgeo import gdal
In [2]: pszFilename =
"/vsis3/grid-dev-publiclidar/estonia/dtm/estonia_dtm_5m.tif"
In [3]: hDataset = gdal.Open(pszFilename, gdal.GA_ReadOnly)
In [4]: hDataset
In [5]: hDataset = gdal.OpenEx(pszFilename, gdal.GA_ReadOnly)
In [6]: hDataset
Out[6]: <osgeo.gdal.Dataset; proxy of <Swig Object of type
'GDALDatasetShadow *' at 0x7f827217c450> >
In [7]: hDataset.GetGeoTransform()
Out[7]: (365000.0, 5.0, 0.0, 6635000.0, 0.0, -5.0)
Mike
*From: *Even Rouault <even.roua...@spatialys.com>
*Date: *Saturday, November 19, 2022 at 10:08 AM
*To: *<michael.smith.e...@gmail.com>
*Cc: *gdal-dev <gdal-dev@lists.osgeo.org>
*Subject: *Re: [gdal-dev] errors using IAM instance profile auth in s3
Le 19/11/2022 à 16:00, michael.smith.e...@gmail.com a écrit :
Correct, not a public bucket, which is why the IAM credentials are
needed. If I set them manually, it all works fine.
That's super weird if the result of a range request changes depending
on how credentials have been set... Perhaps enable CPL_CURL_VERBOSE=ON
env variable and diff the logs ?
You could also try the gdal_cp.py sample script at
https://github.com/OSGeo/gdal/blob/master/swig/python/gdal-utils/osgeo_utils/samples/gdal_cp.py
, which is a cp-like utility working with GDAL virtual file systems,
with the 2 authentication methods
python gdal_cp.py
/vsis3/grid-dev-publiclidar/estonia/dtm/estonia_dtm_5m.tif out.tif
(you can interrupt it with ctrl-c after a few seconds. that will be
enough to get the first bytes)
you might need to run an hexadecimal editor to inspect a bit the content.
[ u02]$ export AWS_ACCESS_KEY_ID=xxxxx
Yes, a 206 response code means success here as we are requesting
only bytes 0-16383. So maybe the file is not a valid TIFF ?
( "grid-dev-publiclidar" must not be so public I guess, because
when trying with my credentials, I get a Access Denied)
Le 19/11/2022 à 15:40, michael.smith.e...@gmail.com a écrit :
I’m seeing that it’s getting a 206 response code, so wouldn’t
that indicate auth is working?
gdalinfo
/vsis3/grid-dev-publiclidar/estonia/dtm/estonia_dtm_5m.tif
HTTP: Fetch(http://169.254.169.254/latest/api/token)
HTTP: libcurl/7.86.0 OpenSSL/3.0.7 zlib/1.2.13 libssh2/1.10.0
nghttp2/1.47.0
HTTP: These HTTP headers were set:
X-aws-ec2-metadata-token-ttl-seconds: 10
HTTP:
Fetch(http://169.254.169.254/latest/meta-data/iam/security-credentials/)
HTTP:
Fetch(http://169.254.169.254/latest/meta-data/iam/security-credentials/iam-grid-s3)
AWS: Storing AIM credentials until 2022-11-19T20:42:58Z
S3: Downloading 0-16383
(https://grid-dev-publiclidar.s3.amazonaws.com/estonia/dtm/estonia_dtm_5m.tif)...
S3: Got response_code=206
gdalinfo failed - unable to open
'/vsis3/grid-dev-publiclidar/estonia/dtm/estonia_dtm_5m.tif'.
Mike
On Nov 19, 2022, at 9:26 AM, Even Rouault
<even.roua...@spatialys.com>
<mailto:even.roua...@spatialys.com> wrote:
Hi Mike,
could you send the output of
curl
http://169.254.169.254/latest/meta-data/iam/security-credentials/iam-grid-s3
Slightly redacted of course, but with the exact
formatting. This part of thee code currently uses a
"simple JSON parser"
(https://github.com/OSGeo/gdal/blob/c61d116a469821b769630a112dee7f1a61fed885/port/cpl_aws.cpp#L554),
which is actually just a non JSON-aware string tokenizer,
and I suspect it could be defeated by a new formatting of
S3 or something specific to your credentials.
It could also be that something unhandled by that parser
appears inside quoted strings, like an escaped double
quote or some other JSON escaped character (like an
escaped forward slash \/ )
If that was the case we should likely switch to proper
JSON deserialization (that part of the code must predate
libjson-c being a build requirement of GDAL).
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
