I would like to ask for feedback on a proposal I wrote  for how we
could run a package mirror system on S3. It would be useful if everyone
read it before the meeting so we can discuss it. This is a draft, so I
would appreciate constructive feedback on the mailing list and/or IRC
I know that, you guys, are focused on Amazon's EC2.
Anyway, please, take a look on CloudSigma: http://cloudsigma.com/
- The company supports KVM/Qemu and we all know the benefits of that.
- Their backend is awesome.
- Nice ReST API: http://www.cloudsigma.com/en/platform-details/the-api
- Pay as you go or subscription
- 14 day trial
- They, currently, support Fedora 13.
- They let you upload your ISOs and share them with the community
It's worth a look. This is, by no means, SPAM. I'm not trying to sell
you anything. I'm just a very happy user. I think, Fedora Cloud,
should be aware of these options and see what we can do here too! ;)
I hope this doesn't bother anybody ;)
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
Regardless how MirrorManager is made to work, the content itself will need
to come from S3; I think that's in agreement, right?
When I talked to Ben and Nathan at Amazon about it, Ben mentioned that it is
best to have an S3 account per region for large sites; I agreed, and have
already experienced why this is the case. I can go over the reasons more
extensively if the group would like, but they can be summed with a single
word: "security." I'll give two short examples, both based on what could
happen between Matt and I working on getting MirrorManager in AWS.
While working on the code to get MirrorManager to have an S3 back-end, say I
accidentally send the keypair in an email, or worse - in an email to a list.
Immediately failing over to the second keypair (accounts can only have two
keypairs, and only one should be used at a time except for when you're
changing the keys; the second allows for seamless switches to a new keypair,
as you leave both active until the process is complete, then deactivate the
old one). Having the keys be per-region minimizes the impact of this
problem; there was a temporary exposure, but it wasn't a /global/ exposure,
which means we can safely treat the contents of all the other regions as
clean/untainted still, and either sync from one region to another to make
sure nothing happened during the exposure, or at the very worst only have
one repo to rebuild.
As another example, to help Matt with getting S3 as a backend for
MirrorManager, I would have my productivity greatly increased by having
access to the keypair. Is the only thing on the official fedora account the
S3-backed repositories? I wouldn't think so. However, that keypair allows
access to *everything* at AWS. There is nothing sacred from that keypair; I
can use it to put a pubkey in the authorized_keys file of root on all the
ec2 instances then do things on the servers as root on the servers - as an
example. That keypair is godmode for *all* of the AWS services. Making
distinct per-region accounts that are used just to do S3 buckets protects
you from this. Matt could give me a normal login account on an ec2 server
so I could help test things, and I could use a keypair to work on S3 as a
backend, without worrying that doing so meant I needed access to the
A key per role, per need, more or less. Ben started our convo by trying to
sell me on multi-account setups, but didn't need to; I already work on a
team that needs to insulate itself from mistakes, and from workers who may
not be here next week (and who should therefore not have godmode keys).
There are a number of other reasons for it, if I need to go on ;)
Does that all make sense?
I'll be on a plane during this week's cloud meeting. (I know, I know!
It's like... ironic, or funny, or something.)
Anyone interested in running the meeting? /me looks at jforbes,
gholms, brianlamere.... :)
I just wanted to mentioned that with the release of Eucalyptus 2.0  we
are now providing packages for Fedora. We have been providing a Fedora
image for sometime now (albeit is a fairly old version of Fedora), and we
are happy to be able now to provide packages for Fedora.
Feel free to send me any comment about the packages, or any other
Eucalyptus related question.
Eucalyptus Systems, Inc.