would be nice to support multiple accounts in config

[minism]

A common pattern I see with s3cmd is to maintain multiple config files like this:

http://mikesisk.com/post/s3cmd-with-multiple-accounts

What would be nice is a way to specify multiple sets of keys in s3cmd.config each with an alias, such that s3cmd could be invoked using the alias as an argument to select that account.

Or perhaps that is overkill. What do people think?

[bpeirce]

I would also like to store credentials from multiple AWS accounts in a single .s3cfg file.

[jasonseney]

I agree there should be a way to support multiple accounts.

Perhaps maybe checking for a local config before using the global one in the home folder? This would allow various projects to use s3cmd as normal with different accounts and not complicating or changing the config format.

[eyadsibai]

+1

[brainstorm]

Also, this can be used to support sync between two S3 buckets more transparently between two different accounts. All example usages I find about sync assume that both S3 buckets have the same access-key-ids and secrets:

https://mdahlman.wordpress.com/2013/12/05/copy-files-between-s3-buckets/

I guess that this is harder to implement in a transparent way than it seems, because:

http://www.patcup.com/copy-contents-in-s3-bucket-between-aws-accounts-with-s3cmd/

One needs to define bucket policies in both endpoints beforehand... I guess that this step could be automated as well.

[deadlocks]

+1

[mdomsch]

The sync (remote to remote copy) only sends the command to the destination
server using your access_key (valid on the destination server). That key
must also have read access to the objects in the source bucket. The
destination server then copies the data from the source bucket directly.
There's only one set of keys in use during this operation.

On Wed, Feb 4, 2015 at 3:47 AM, Roman Valls Guimerà <
notifications@github.com> wrote:

Also, this can be used to support sync between two S3 buckets more
transparently between two different accounts. All example usages I find
about sync assume that both S3 buckets have the same access-key-ids and
secrets:

https://mdahlman.wordpress.com/2013/12/05/copy-files-between-s3-buckets/

—
Reply to this email directly or view it on GitHub
#104 (comment).

[hexinpeter]

Mike has a nice solution to using multiple accounts with s3cmd. http://mikesisk.tumblr.com/post/8703449578/s3cmd-and-multiple-accounts

[adamberenzweig]

Why not have s3cmd support the new standard .aws/credentials file? http://blogs.aws.amazon.com/security/post/Tx3D6U6WSFGOK2H/A-New-and-Standardized-Way-to-Manage-Credentials-in-the-AWS-SDKs

[eyadsibai]

+1 @adamberenzweig

[mdomsch]

I'd consider a patch to accept the .aws/credentials file as valid input.

On Thu, Apr 16, 2015 at 10:43 AM, Eyad Sibai notifications@github.com
wrote:

+1 @adamberenzweig https://github.com/adamberenzweig

—
Reply to this email directly or view it on GitHub
#104 (comment).

[vladimirmartsul]

+1

[ijstokes]

+1

[edencorbin]

+1, multiple configs would be my preference perhaps s3cmd configure myConfig1 or the like.

[jedsundwall]

+1

[fviard]

Something that could be done is that you create a .s3cfg file without access_key and secret_key.
And set them per your needs through env variables:
AWS_ACCESS_KEY and AWS_SECRET_KEY
you can probably have an alias or little bash script that does that for you.

Otherwise, I'm not sure that a "profile" option would have much sense.
What is more convenient to type? Something like:
s3cmd -c s3cfg_florent ls
s3cmd -c s3cfg_corporate ls
or
s3cmd -c s3cfg -p florent
s3cmd -c s3cfg -p corporate

The later will create more configuration confusion for basic users I think?

The point being that from a first view, you can think that in profile should go:
"access_key", "secret_key", "access_token"

But some other people that use encryption or servers that are not aws s3 could consider that the following are also like "profiles":

• kms_key
• encrypt
  -gpg_passphrase
• use_https
• signature_v2
• host_base
• host_bucket

So, in the end you will want to override most of the fields that are commonly modified in s3cfg file.
But that is just my opinion ;-)