mirroring for alternative content

Colin Walters walters at verbum.org
Sat Jun 21 14:25:47 UTC 2014


We have several forms of non-Koji internal builds:

1) COPR (the most visible)
2) http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/  (this
could be a COPR)
3) rpm-ostree: http://rpm-ostree.cloud.fedoraproject.org/#/

Now, I recently was allocated a new atomic01.qa.fedoraproject.org server
dedicated to rpm-ostree composes, and I'm happy to announce I now have
it composing trees:

fedora-atomic/rawhide/x86_64/server/docker-host =>
fedora-atomic/rawhide/x86_64/workstation/gnome/core =>

But it's on the QA network, and so I can't just serve the content
directly from it.  Nor would I want to have the compose server doing
double duty as a static webserver anyways.

I could just rsync this content to the current
rpm-ostree.cloud.fedoraproject.org, but there are a few issues with

1) It's a one off instance in the fedora cloud with no backup/monitoring
2) No redundancy
3) No tuning for static webserving
4) Most critically, no TLS

COPR only relatively recently gained TLS, which is fundamentally
necessary for retrieving arbitrary executable code that runs as root.

But COPR also (from what I understand from <puiterwijk>) is just one

What do you think about investing in having e.g.
altcdn.fedoraproject.org be a load-balanced static webserver farm
protected by TLS that could be written to by a trusted subset of
non-Koji build/compose tooling?

"altcdn" is the first thing that came to mind offhand for a name, feel
free to pick others =)

We'd need to determine the writing process; could be rsync-over-ssh
access to specific subdirectories gated by ssh key?  Something else?

More information about the infrastructure mailing list