Changing the region of alces-flight-XXX bucket


#1

I’ve got my alces-flight-${cw_INSTANCE_aws_account_hash} bucket in one of US regions. If I delete it and start a cluster in another region, will a bucket be created in that region?
More generally, is it possible to easily change $cw_INSTANCE_aws_account_hash so that a bucket appropriate for the region is used? I understand there could be a situation when a single bucket is a good thing (e.g. you can use any region). But I started digging into alces sync which uses the same bucket and it seems a bit odd to push/pull across regions.
I want to be able to provision clusters for different users and set up access controlled bucket so that each user can save files in a separate folder protected from others. However alces sync seems as a potentially good fit because it offers much of what I need (and exclusions) and accessibility can be controlled by using different user names and pass phrase encryption. A bit limiting but perhaps we can live with this.
However being restricted to one specific region is too much. Have I missed something?
Thanks!


#2

I deleted the alces-flight- bucket but it was re-created again in US East region. The name is absolutely the same though. Presumably I can delete it again and create manually in the region I want it to be in.
A better solution might be to use Profile Bucket and Profile name if they were provided.

Regarding the passphrase, I am not prompted for it. And in fact, how would home directory be initialised (sync’d) during the first login if the files were passphrase protected?


#3

Yes, that’s right – the bucket is created if it doesn’t yet exist, otherwise the existing bucket will be used. Currently, when the bucket is automatically created no region is specified, so it will be created in the default region for S3, which is us-east-1. Thinking about it, it would probably make more sense for the automatic creation of the bucket to use the region that is being used for Flight Compute; I’ll pass that on to the development team.

If any files have been passphrase protected you should receive a prompt each time alces sync pull is used, including on first login. If no files have been pushed with a passphrase then no prompt is shown.

You should be prompted for the passphrase on alces sync push if you’ve added a pattern to the encrypt section of the corresponding sync configuration file that matches one or more files. It’s also worthwhile noting that any matching patterns in the exclude section will override those in the encrypt section.


#4

Thank you for your patience and help! As a workaround, I deleted the bucket and re-created it in EU.

However after additional experimentation with getting alces sync to work with encryption it is still tricky for me to manage user access. Encryption is needed because IAM allows the instance access to the whole of the bucket. (I suppose I could tweak S3 permissions based on profile name which can be related to a user).
When I added a file to be sync’ed as encrypted I got a prompt for passphrase but the file did not appear to be encrypted on S3.
At least s3cmd encrypted files show gpg encryption through metadata.
And it looks like if I configure s3cmd myself, the presence of .s3cfg confuses alces sync. It is no longer able to access synchronization bucket.


#5

It’s possible that the file(s) is(/are) being uploaded both unencrypted and encrypted. There are some combinations of pattern specifications in the configuration file that can cause this – for example, if a file matches patterns in both the include section and the encrypt section. If this is happening, you might be able to create a working configuration by removing the pattern from the include section.

Note that encrypted files do not appear in the bucket as objects but, instead, are held in a .dat object named for the sync configuration under the /sync/<username> prefix, e.g. /sync/alces/default.dat. If you’re still seeing files you think should be encrypted after an alces sync push, you could try a fresh sync by purging the existing files first using alces sync purge beforehand.

Adding a .s3cfg file may have an impact on the operation of alces sync depending on the credentials specified. If you leave the access_key and secret_key parameters blank then it should be able to access the bucket with the instance credentials. However, using GPG encryption with alces sync (i.e. setting encrypt = True in .s3cfg) will cause failures as the underlying s3cmd sync command doesn’t support GPG.

HTH!