search

irods / irods_resource_plugin_s3

S3-compatible storage resource plugin for iRODS
Other
13 stars 16 forks source link

provider requires S3_AUTH_FILE to exist #1837

Open othmar-weber opened 7 years ago

othmar-weber commented 7 years ago

We have an environment with an icat server and multiple resource servers that host s3 resources. Trying to access data from the S3 resource we see the following message in the log of the catalog server:

Apr 6 16:07:50 pid:35903 ERROR: [-] libirods_s3.cpp:1690:s3StartOperation : status [SYS_CONFIG_FILE_ERR] errno [] -- message [Failed to read S3 auth info.] [-] libirods_s3.cpp:473:s3ReadAuthInfo : status [SYS_CONFIG_FILE_ERR] errno [] -- message [Failed reading the authorization credentials file.] [-] libirods_s3.cpp:448:readS3AuthInfo : status [SYS_CONFIG_FILE_ERR] errno [] -- message [Unknown error in authorization file.]

On the client side the iget command is successful and the error message is not shown.

If I create a dummy file on the icat server with the same path which is specified in S3_AUTH_FILE for the S3 resource the message disappears. The dummy file needs to have at least two lines otherwise I get the following message on the icat:

Apr 6 16:09:12 pid:35956 ERROR: [-] libirods_s3.cpp:1690:s3StartOperation : status [SYS_CONFIG_FILE_ERR] errno [] -- message [Failed to read S3 auth info.] [-] libirods_s3.cpp:473:s3ReadAuthInfo : status [SYS_CONFIG_FILE_ERR] errno [] -- message [Failed reading the authorization credentials file.] [-] libirods_s3.cpp:441:readS3AuthInfo : status [SYS_CONFIG_FILE_ERR] errno [] -- message [Read 0 lines in the auth file. Expected 2.]

trel commented 5 years ago

Need to check if this is still the case.

PaulVanSchayck commented 3 years ago

This is still the case, just seen it on a 4.2.10 install with the 4.2.10.0 plugin.

trel commented 2 years ago

So, this means the S3 resource plugin code is checking for the S3 auth file on every host... not just the one that should be checking (aka, the server that will be talking to S3 itself).

Because we're executing the start operation in the resource plugin constructor?

And every agent executes the constructor for all its plugins upon agent startup...

https://github.com/irods/irods_resource_plugin_s3/blob/17e98f0e8f21a1d6b731ecd7a0287421b214249e/s3/libirods_s3.cpp#L2430-L2433

So... this suggests we should do some hostname checking before looking for the auth file.

luijs commented 1 year ago

Just saw this happening on a 4.3.0 install as well. Installing credentials on every machine, instead on just the one hosting the resource is the workaround for now I guess. Problem might be, if you run a resource in detached mode, you SHOULD have the credentials on every machine that has the plugin.

trel commented 1 year ago

@luijs Yes, certainly if running in detached mode, then all servers will attempt to connect to S3 themselves - and the credentials will need to be present on that machine.